ESDfTR-78-l39 


— — ^ 

^('/N^IR^ORCE  CUlOE  TO  THE^OMPUTER  f 

IOIpROgram^evelopment  specification  / 




m 


FOR.  FURTBER  TRAH  W 


I Lloyd  VySeorle/ 

System  development  Corporation 
2500  Colorado  Avenue 
Santa  Monica,  CA  90406 


( *'/&/  / r.-d  ( p I 


illjL 


O 

\ 


I uS^fIIt:£22dIill 

l>—  Approved  for  Public  Release; 
V Distribution  Unlimited. 


1 


Prepared  for 

DEPUTY  FOR  TECHNICAL  OPERATIONS 
ELECTRONIC  SYSTEMS  DIVISION 
HANSCOM  AIR  FORCE  BASE,  MA  01731 


5^/ 0 6 21  04  3 


LEGAL  NOTICE 

When  U.  S.  Government  drowings,  specifications  or  other  data  are  used  for  ony 
purpose  other  than  a definitely  related  government  procurement  operation,  the 
government  thereby  incurs  no  responsibility  nor  any  obligation  whatsoever;  and 
the  foct  that  the  government  may  hove  formulated,  furnished,  or  in  any  way  sup- 
plied the  said  drawings,  specifications,  or  other  data  is  not  to  be  regarded  by 
implication  or  otherwise  as  in  any  manner  licensir>g  the  holder  or  any  other  person 
or  conveying  any  rights  or  permission  to  manufacture,  use,  or  sell  any  patented 
invention  that  may  in  any  way  be  related  thereto. 


OTHER  NOTICES 


Do  not  return  this  copy.  Retain  or  destroy. 

This  technical  report  has  been  reviewed  and  is  approved  for  publication. 


JOHN  C.  MOTT-SMITH 
Project  Manager 


JOHN  T.  HOLLAND,  Lt  Colonel,  USAF 
Chief,  Techniques  Engineering  Division 


FOR  THE  COMMANDER 


STANLEY  P</DEra:aKA,  Colonel,  USAF 
Director,  Computer  ^sterna  Engineering 
Deputy  for  Technical  Operations 


UNCLASSIFIED 


REPORT  DOCUMENTATION  PAGE 


SCCURtTV  CLASSIFICATION  OF  THIS  PACE  Datm  Enr«r«d; 


READ  INSTRUCTIONS 
BEFORE  COMPLETING  FORM 


2 govt  accession  no. I s RECIPIENT'S  CATALOG  NUMBER 


S.  TYPE  OF  REPORT  A PERIOD  COVERED 


4.  TITLE  SubllllA) 

An  Air  Force  Guide  to  the  Computer  Program 
Development  Specification 


7.  AuTHORFtJ 

Lloyd  V.  Searle 


II  CONTROLLING  OFFICE  NAME  AND  ADDRESS 

Deputy  for  Command  and  Management  Systems 
Electronic  Systems  Division 


S CONTRACT  OR  GRANT  NUMBER(«j 

F19628-76-C-0236 


10  PROGRAM  element.  PROJECT,  TASK 
AREA  A WORK  UNIT  NUMBERS 


12  REPORT  DATE 


March  1978 


<3  NUMBER  OF  PACES 

103 


4 MONITORING  AGENCY  NAME  A AOORESSflf  dl//#f#nl  Irom  Controlling  OlHco)  '5.  SECURITY  CLASS,  (ol  thlt  roport) 

Unclassified 


IS  DISTRIBUTION  STATEMENT  (ol  lhl«  Report) 

Approved  for  Public  Release;  Distribution  Unlimited 


17  DISTRIBUTION  STATEMENT  (ol  the  sbeiroct  entered  tn  Block  70,  U dlllerent  hom  Report) 


IS-  KEY  WORDS  fConflnu*  on  tevetee  elde  II  neceeemry  and  Identity  by  block  number) 

Computer  Program  Specifications  System/ Software  Acquisition  Management 

Computer  Program  Management  Software  Documentation 

Computer  Program  Acquisition  Management  Software  Configuration  Management 
System  Acquisition  Management 

Computer  Program  Configuration  Management 


20.  ABSTRACT  fConilnuo  on  eaearaa  aide  If  naeaaaary  and  Idantify  by  block  numbar) 

This  report  provides  explanatory  guidance  and  examples  to  support  the  effective 
preparation  and  evaluation  of  development  specifications  for  computer  programs. 
It  is  one  of  a series  of  guidebooks  prepared  to  assist  members  of  Air  Force  pro- 
ram offices  in  managing  the  software  aspects  of  military  system  acquisitions, 
he  guide  contains  an  introductory  section  which  outlines  the  manner  in  which 
requirements  for  computer  programs  should  be  developed  during  the  conceptual 
and  validation  phases  of  a system  program,  including  attention  to  implications 


UNCLASS IF 


ICCUVITU  CtAilttlC ATION  or  THIS  Of 


ZO/Vcont'd) 


contractor  personnel.  The  body  of  the  guide  is  devoted  to  descriptions  of  the 
proper  emphasis  and  level  of  content  for  each  section  and  paragraph  of  a com- 
pleted specification  when  prepared  in  accordance  with  the  instructions  contained 
in  MIL-STD-483  for  the  computer  program  development  (Part  I,  or  Type  B5) 
specification. 


' c\ 


' \ 


\ 


UNCLASSIFIED 


SCCUAITV  CL  AS&iriC  ATiOH  THIS  rACCfWKan  Pat#  Fnt«re<P 


PREFACE 


This  guide  is  one  of  e series  of  Sofewere  Acquisition  MansgeMnt  (SAM) 
guidebooks  being  sponsored  by  the  Electronic  Systems  Division  (ESD)  of  Air 
Force  Systems  Commend.  The  purpose  of  the  series  ss  s whole  is  to  assist 
members  of  system  program  offices  in  managing  the  software  aspects  of 
military  system  acquisitions. 


Air  Force  msnagement  of  the  SAM  guidebook  program  is  being  provided  by  ESD's 
Directorate  of  Computer  Systems  Engineering  (ESD/TOI).  Administrative 
guidance,  review,  and  technical  coordination  of  this  guidebook  have  been 
accomplished  for  ESD/TOI  by  the  project  mansger,  Mr.  John  Hott-Smith. 


The  SAM  guidebook  series  consists  of  individual  documents  issued  as  they  are 
completed  in  the  form  of  ESD  technical  reports.  The  first  seven  reports  of 
the  series  were  prepared  by  members  of  the  MITRE  Corporation  and  published 
during  the  period,  1975-1977.  Additional  guidebooks  to  complete  the  scries, 
including  this  one,  are  being  prepared  by  the  System  Development  Corporation 
(SDC)  under  Air  Force  contract  #F19628-C-76-0236.  SDC's  manager  responsible 
for  the  project  is  Mr.  Harvey  I.  Gold. 


Assistance  in  preparing  materials  for  this  guide  to  the  computer  program 
development  specification  has  been  provided  by  Mr.  Stsnley  G.  Benson  of  SDC, 
to  whom  the  writer  is  Indebted  for  saatples  of  specification  content  used  in 
some  of  the  Section  3 illustrations.  Of  particular  note  are  the  functional 
diagrams  Illustrated  in  Figures  9 and  10,  which  Mr.  Benson  has  developed  for 
his  own  past  uses  in  documenting  system  engineering  analyses  of  computer 
program  requirements. 


Topics  covered,  and  to  be  covered,  in  the  SAM  series  as  a whole  are  identified 
in  the  following  list.  National  Technical  Information  Service  (NTIS)  acces- 
sion numbers  shoim  in  parentheses  identify  those  topics  for  which  guidebooks 
have  already  been  published,  and  for  which  copies  are  available  through  that 
service. 

e Regulations,  Specifications  and  Standards  (AD-A016401) 
e Contracting  for  Software  Acquisition  (AD-A020444) 
e Monitoring  and  Reporting  Software  Development  Status  (AD-A016488) 
e Statement  of  Work  Preparation  (AD-A035924) 

# Software  Documentation  Requirements  (AD-A027051) 
e Software  Development  and  Maintenance  Facilities  (AD-A038234) 
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• Life  Cycle  Bvente  (AD-A037115) 
e Reviewe  and  Audita 

e Configuration  Manageaent  (AD-A047308) 
e Coaqputer  Prograa  Development  Specification 
e Verification  (AD-A048S77) 
e Validation  and  Certification 
e Overview  of  the  SAM  Guidebook  Seriea 
e Software  Maintenance 

e Software  Quality  Aaaurance  (AD-A047318) 
e Software  Coat  Eatlaation  and  Meaaureaent 
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SECTION  1.  INTRODUCTION 


This  guidebook  is  written  to  support  measures  being  taken  by  the  Air  Force  to 
improve  the  management  of  software  in  system  programs.  Its  general  concern  Is 
with  the  topic  of  how  to  manage  the  analysis  and  documentation  of  adequately- 
defined  requirements,  during  early  phases  of  a system  program,  as  a basis  for 
initiating  and  controlling  contracts  for  computer  program  development.  As  a 
key  aspect  of  that  general  problem,  major  emphasis  is  placed  in  this  guide- 
book on  explanations  and  examples  which  are  designed  to  clarify  and  supplement 
the  brief,  but  significant,  ipstructions  provided  in  current  military  standards 
to  govern  the  format  and  content  of  the  computer  program  development  specifica- 
tion. 

The  guidance  is  addressed,  jointly,  to  contractor  and/or  Government  personnel 
responsible  for  developing  and  preparing  the  specification,  and  to  personnel 
of  Air  Force  system  program  offices  who  are  responsible  for  its  evaluation, 
acceptance,  and  subsequent  control. 


It  has  been  noted  in  studies  of  problems  encountered  with  computer  program 
acquisition  in  systems  that  success  or  failure  is  often  a direct  function  of 
how  well,  or  whether,  the  acquisition  was  initiated  on  the  basis  of  well  de- 
fined and  properly  documented  technical  requirements.  The  development  of 
those  technical  requirements  is  in  Itself  a complex  and  lengthy  process. 
Considered  very  generally,  it  involves: 

• First  developing  a system  specification  which  includes  requirements  for 
infonnatlon  processing  functions  at  the  appropriate  levels  and  properly 
integrated  with  requirements  for  the  system  as  a whole, 

• Accomplishing  proper  allocations  of  system  functions  to  the  various  system 
elements  to  be  developed  or  otherwise  acquired,  including  computer  programs. 

• Analyzing,  evaluating,  and  expanding  those  functions  and  associated 
performance  requirements  which  have  been  allocated  to  Indivldually-idenr.i- 
fied  computer  program  configuration  items  (CPCIs). 

e Finally,  for  each  identified  CPCI  to  be  developed  for  the  given  system, 
formulating  detailed  definitions  of  the  requirements  and  documenting  chose 
in  Che  form  of  a coisputer  program  development  (Type  B5,  or  Part  I*)  speci- 
fication. 


*Among  the  standard  specification  types  and  subtypes  prescribed  for  military 
uses,  Che  computer  program  development  specification  is  Type  BS.  Fqr  a given 
developmental  CPCI,  Che  Type  B5  and  subsequent  Type  C5  (product)  specifica- 
tions are  normally  identified  as  one,  two-part  specification,  of  which  the 
B5  is  Parc  I and  the  C5  is  Part  II.  Hence,  Che  subject  specification  is 
referred  to,  interchangeably,  as  the  Type  B5,  development,  or  Part  I CPCI 
specification. 
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Since  all  of  Chose  successive  steps  of  analysis  and  definition  have  a direct 
bearing  on  the  adequacy  of  computer  program  requirements,  a summary  overview 
of  that  total  process  Is  presented  below  as  a part  of  this  first.  Introduc- 
tory section.  However,  the  focus  of  attention  In  the  body  of  this  guidebook 
Is  on  the  last  of  those  four  generalized  steps.  That  emphasis  derives  In 
part  from  considerations  of  space  and  available  Information,  since  the 
process  outlined  Is  lengthy,  complex,  and  subject  to  many  normal  variations 
In  methods  and  procedures.  But  attention  to  the  end  objectives  Is  also  indi- 
cated as  a logical  "first  step"  in  any  further  detailing  of  the  generalized 
process  as  a whole.  Judging  from  many  samples  of  Part  I CPCI  specifications 
which  have  been  examined,  the  Initial  need  Is  for  a better  common  perception 
of  Che  desired  end  product  than  appears  yet  to  exist. 


a. 

1.1  SPECIFICATION  ROLES  AND  OBJECTIVES  - GENERAL 

Current  specification  standards  for  computer  programs  are  designed  to  be 
compatible  with  ttve  Air  Force/DoU  structure  of  uniform  specifications  approved 
for  use  In  defense  system  acquisitions.  Vilhile  the  standards  are  potentially 
useful  for  broader  application,  certain  aspects  of  the  uniform  specification 
structure  and  content  tend  to  be  both  peculiar  and  significant  to  Che  military 
system  practices.  In  the  Air  Force,  in  particular,  the  specifications  are 
integrated  with  a spectrum  of  related  management  concepts  and  practices  whicli 
are  typical  of  the  system  phasing  and  environment — notably,  pertaining  to 
configuration  management,  data  management,  the  test  program,  and  contracting. 


Air  Force  practice  is  to  require  (a)  one  performance-level  specification 
prepared  for  a sv'stem  as  a whole,  and  (b)  one  specification  for  each  develop- 
mental, Government  inventory,  or  commercial  "off-the-shelf"  end  item.  For 
each  developmental  Item,  the  specification  is  prepared  in  two  successive 
parts:  Part  I (the  development  specification),  defining  primarily  performance- 
level  requirements  to  govern  the  item's  development;  and  Part  II,  (the  product 
specification),  defining  detail  design  and  construction  of  the  developed  item. 
This  approach  to  the  structure  of  specifications  for  a system  evolved  and 
became  firmly  established  within  the  Air  Force  Systems  Command  during  the 
early  1960s.  A few  of  the  associated  principles  and  implications  which  are 
significant  to  the  purposes  and  orientation  of  this  guidebook  are  summarized 
as  follows: 

• Tne  system  specification  performs  important  functions  in  governing  the 
svstem  program — i.e.,  the  time-phased  series  of  activities  and  events 
through  which  the  system  is  brought  into  being — as  well  as  in  defining 
the  general-level  configuration  of  the  requirefl  system.  Tills  relation- 
ship is  depicted  in  Figure  1.  It  is  fundamental  to  the  level  and 
scope  of  the  system  specification  that  its  requirements  function  as  the 
basis  for  extensive  efforts,  during  the  course  of  the  system  program,  to 
derive,  analyze,  and  detail  the  specification  of  requirements  for  indivi- 
dual items. 
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Figure  1.  Funcclons  and  Coverage  of  the  System  Specification  (see  text). 


• The  system  specification  covers  broad  requirements  to  be  met  by  both 

Government  agencies  and  contractors,  including  significant  requirements  for 
system  elements — such  as  personnel  and  facilities — which  cannot  normally  be 
acquired  through  contracts  administered  by  the  system  program  office.  It 
has  no  direct  counterpart  at  the  product  level — i.e.,  there  is  no  "system 
design  specification".  Specifications  for  design  and  construction  are 
prepared  only  for  those  portions  of  the  system  that  consist  of  defense 
materiel  items,  and  only  for  each  item  individually. 

e In  those  respects,  the  system  speclflcatio.i  reflects  established  Air  Force 
philosophy  that  a system  is  not  acquired  as  an  entity,  but  as  a collection 
of  individually-identified  end  items.  While  some  (partial)  exceptions  have 
occurred,  that  principle  is  basic  not  only  to  the  structure  of  uniform 
specifications  but  to  a spectrum  of  the  current  standards  and  practices  of 
system  acquisition  management.* 

a A major  first  step  in  a system  program,  following  completion  and  issuance 
of  the  initial  system  specification,  is  to  identify  the  required  end  items 
of  defense  materiel  and  to  document  detailed  requirements  for  those  items 
in  the  form  of  item-level  specifications  appropriate  to  the  clash  of  item 
and  intended  approach  to  its  acquisition.  This  step  is  accomplished  through 
system  engineering  studies  which  result  in:  (a)  matching  some  requirements 

*See  amplifying  NOTE  on  this  point,  p.  11. 
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with  Items  already  In  existence,  and  providing  Inventory  or  product  function 
specifications  for  those;  and  (b)  allocating  other  requirements  to  items  to 
be  newly-developed,  and  providing  performance-level  (Part  I)  specifications 
for  those  items. 


• Prominent  activities  during  the  full-scale  development  phase  of  a system 
program  are  governed  most  directly  by  the  Part  I specifications.  Develop- 
ment contracts  are  primarily  for  the  performance  of  developmental  tasks. 
Vlhlle  those  may  include  tasks  of  system  engineering/integration  or  support 
of  system  testing,  they  are  predominantly  for  analysis,  design,  fabrica- 
tion, assembly,  testing,  and  documentation  of  the  individual  items.  Those 
portions  of  each  contract  are  basically  satisfied  when  (a)  the  items  are 
formally  qualified  against  their  Part  I specification  requirements  and  (b) 
their  detail  design  and  construction  are  properly  documented  in  the  form  of 
Part  II  (product)  specifications. 


• For  equipment  elements  of  a system,  the  later  actual  procurement  of  end 
items  is  accomplished  through  the  use  of  product-level  (l.e.,  inventory, 
product  function,  or  Part  II)  specifications,  which  typically  serve  as  the 
technical  requirements  instruments  to  govern  item  requisition,  purchase, 
or  production.  Thus,  for  newly- developed  equipment  items,  the  Part  II 
specifications  themselves  represent  major  products  of  a system  full-scale 
development  phase — not  the  items  as  such.  In  the  model  system  program 
addressed  in  the  DoD  5000-series  directives,  and  for  the  most  part  in  the 
Air  Force  800-serles  regulations,  the  question  of  whether  the  Part  II 
specifications  are  put  to  use  for  actual  acquisition  is  a major  decision 
to  be  reserved  for  the  end  of  that  phase.* 


• Except  for  the  last  point  mentioned,  computer  program  specifications  are 
designed  to  fit  into  that  process  essentially  as  outlined.  Including 
relations  to  the  system  specification.  The  notable  difference  is  that  the 
Part  II  specification  for  a computer  program  item  is  developed,  in  conjunc- 
tion with  development  of  the  CPCI,  not  as  a requirements  document  to  be 
used  for  subsequent  procurement  but  purely  as  an  "as  built"  technical 
description  of  the  developed  item.  Time  and  expense  required  to  duplicate 
(produce)  a computer  program  in  quantity  for  system  deployment  are  typically 
trivial.  One  important  consequence  is  that  the  CPCI  Part  I specification 
— the  subject  of  this  guidebook— serves  the  dual  purpose  of  governing  the 
actual  item  acquisition  as  well  as  its  development. 


*Current  policy  in  this  respect  tends  to  emphasize  circumstances  that  are 
likely  to  be  typical  of  major  ballistic  missile  or  aircraft  systems.  It 
would  also  appear  to  apply  to  a major  electronic  system  when  the  Intent  is 
to  produce  the  system  as  a whole  in  quantity — although  it  does  not  clearly 
address  certain  questions  of  equipment  production  phasing  vdtlch  arise 
regarding  those  as  well  as  for  smaller  or  "one-of-a-kind"  systems.  It  does 
not  clarify,  for  example,  how  to  manage  the  production  of  significant  items 
which  may  be  needed  in  order  to  conduct  the  system  test  program. 
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MOTE:  Objections  have  been  expressed  to  stateaenta  made  above  (second  para- 
graph. page  9),  on  the  basis  that  they  contradict  a notion  chat  Che  Air  Force 
acquires  each  systea  as  an  entity.  As  a whole,  tho  preceding  brief  discussion 
of  specification  roles  is  Intended  only  to  suaasHre,  not  Co  explain  nor 
necessarily  defend,  relationshipa  which  are  inherent  in  current ly-docuaented 
standards  and  normal  practice.  As  indicated,  there  are  soae  partial  excep- 
tions. However: 

# Acquiring  a total  systea  "as  an  entity"  from  one  contractor  is  not 

possible,  considering  the  accepted  Air  Force  definition  of  a system  and 
Che  corresponding  content  of  a system  specification  (see  Figure  1 and  the 
first  paragraph,  page  9). 

a In  a few  programs,  contracts  have  been  negotiated  against  Che  system 
specification  itself,  calling  for  delivery  of  an  integrated  assembly  of 
Chat  contractor's  end  items  (e.g.,  COBRA  DANE).  When  chat  contracting 
method  is  chosen,  it  implies  significantly  less-active  PO  management  at 
Che  end-item  level  during  acquisition.  Normal  procedures  in  many  areas 
— as  regards  specifications,  configuration  management,  Che  test  program, 
design  reviews,  management  reporting — do  not  apply  as  prescribed  in  the 
standards.  Consistently  with  Che  level  of  his  contract  responsibility 
for  delivering  an  integrated  end  product,  Che  contractor  retains  control 
throughout  development  over  the  selection,  design,  and  construction  of 
component  end  items,  including  changes  (e.g.,  note  Che  "record-only" 
classification  of  ECPs  described  in  paragraph  4. 3. 2. 5 of  MIL-STO-480). 

e When  Cl-level  specifications  are  placed  on  contract  (the  normal  approach), 
PO  acceptance  also  occurs  at  that  level.  The  system  specification  may 
also  be  cited,  together  with  contractor  casks  in  such  areas  as  system/ 
design  Intcgijtlon  and  interface  control.  And  in  some  cases  the  attempt 
has  been  made  to  establish  the  system  specification  as  having  precedence 
over  the  Cl  specifications.  Legal  rulings  resulting  from  litigations  on 
that  point  have  indicated,  however,  that  the  binding  order  of  precedence 
to  a contractor  is  actually  the  reverse — l.e. , the  contractor  must  comply 
with  the  lowest  level  specification  or  requirement  whenever  there  is  a 
conflict  with  any  higher-level  specification  or  requirement  cited  in  the 
contract. 
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1.2  OVERVIEW  OF  REQUIREMENTS  DEVELOPMENT* 


The  following  description  is  based  on  system  phasing  concepts  set  forth  in 
current  Air  Force/DoU  documents  governing  defense  system  acquisitions.  It 
should  be  recognized  that  the  process  outlined  represents  only  one  among 
various  alternative  approaches  available  to  program  managers.  With  respect 
to  the  conduct  of  a validation  phase,  in  particular,  it  should  also  be 
recognized  that  some  aspects  of  the  process  are  presently  based  more  on 
selective  analysis  of  the  regulations  and  standards  than  on  actual  experience, 
in  that  very  few  system  programs  in  t)>e  past  several  years  have  included  a 
validation  phase.  That  circumstance  is  believed  to  be  one  of  the  important 
reasons  for  the  frequent  Inadequacies  of  documented  system  and  software 
requirements. 


1.2.1  The  System  Specification 

A system  program  is  initiated  for  the  purpose  of  providing  new  or  improved 
military  capabilities  required  by  an  operational  command.  The  Initiation  of 
a given  program  occurs  during  the  conceptual  phase,  as  the  result  of  an 
iterative  process  during  which  alternative  system  concepts  are  examined  in 
relation  to  documented  operational  requirements  and  a proposed  system  is 
selected  on  the  basis  of  estimated  performance,  feasibility,  and  coat  factors. 
A simplified  summary  of  that  process  and  its  major  end  products  is  illustrated 
in  Figure  2,  derived  from  descriptions  of  Air  Force  policy  and  concepts 
pertaining  to  the  conceptual  phase  which  are  provided  more  fully  in  AFSCT 
800-3  (Chapter  2). 

The  most  prominent  technical  pr«.>duct  of  the  conceptual  phase  is  an  initial 
system  specification,  prepared  in  accordance  with  MIL-STD-4'K)  Type  A format. 

At  that  time,  its  primary  purpose  is  to  define  the  technical  portion  of  docu- 
mented program  requirements  to  he  evaluated  and  approved  by  higher  headquar- 
ters before  proceeding  to  the  next  phase.  After  that  review  and  approval,  it 
is  established  as  the  functional  baseline  for  purposes  of  configuration 
management . ** 


"Requirements"  set  forth  in  the  system  specification  should  be  concerned 
primarily  with  the  operational  mission  functions  and  associated  performance 
capabilities  which  the  system-to-be-developed  must  provide,  as  a total  system. 
Emphasis  is  placed  on  defining  and  expanding  those  functional  and  performance 


* The  Life  Cycle  guidebook  (Clore,  see  ref.  9 ) also  includes  a summary 

account  of  the  conceptual  and  validation  phases,  but  from  a quite  different 
point  of  view;  the  overlap  in  coverage  wltli  materia',  in  this  overview  of 
requirements  development  is  relatively  slight. 

**The  document  referred  to  as  "the"  system  specification  is  rarely  a single 
document  in  fact.  It  may  consist  of  multiple  volumes;  and  much  of  its 
effective  content  is  nearly  always  specified  by  reference  to  associated 
system  engineering  documentation,  militarv  specifications  and  standards, 
and  other  documents  which  it  identifies  as  applicable. 
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Figure  2.  Synoptic  Diagram  of  Conceptual  Phase  Events » Activities,  and  Major  Products 


requirements  to  levels  at  which  they  can  be  grouped  Into  functional  areas 
(system  segments)  and  allocated  to  system  physical  elements — of  the  user 
organization  and  major  end  Items  of  equipment,  computer  programs,  and  facili- 
ties. Additionally,  based  on  functional  analysis  and  design  studies  guided 
by  those  decisions,  requirements  are  also  specified  for  logistic  support 
functions  and  design,  personnel  and  training,  including  training  facilities 
and  equipment,  and  system  test. 


As  a practical  matter,  the  level  of  detail  at  which  functions,  performance, 
and  design  are  specified  varies  as  a function  of  available  information  and 
how  well  the  conceptual  phase  system  engineering  studies  have  actually  been 
carried  out.  But  the  level  of  detail  specified  should  also  be  expected  to 
vary  considerably  in  a properly-prepared  specification.  For  example,  precise 
detail  is  appropriate  in  areas  where  design  requirements  or  constraints  exist 
and  have  been  determined  to  be  essential.  In  general,  however,  the  initial 
system  specification  should  carefully  avoid  specifying  levels  of  detail --with 
respect  to  either  performance  or  design — which  mlglit  unnecessarily  limit  the 
latitude  of  design  solutions  to  be  readied  at  later  stages. 


a . System  Functions  and  Performance 

Basic  Information  to  be  provided  in  t)ie  system  specification  consists  of 
statements  which  delineate  the  system  operational  and  support  concepts,  in 
terms  of  its  mission  as  viewed  by  the  intended  operational  user.  These 
statements  provide  the  limiting  criteria  for  further  development  of  the 
system  configuration  and  performance,  in  the  following  areas: 

• Operational  Employment.  Tlie  system  mission  is  defined  in  terms  of  its 
operational  objectives  and  relat ions)iip  to  other  systems.  This  informa- 
tion should  include:  description  of  the  intended  strategic,  tactical,  or 
defense  roles  of  tlie  system  and  its  operating  Interfaces  with  other  systems; 
definitions  of  the  operating  environment (s)  and  operating  modes;  and  defi- 
nitions of  major  performance  parameters  to  be  achieved.  For  an  air  defense 
system,  for  example,  the  focus  is  on:  functions  of  air  surveillance, 
threat  detection  and  assessment,  identification  and  engagement  of  targets, 
and  reporting;  limiting  performance  parameters  in  such  areas  as  tracking 
accuracies,  total  numliers  of  tracks  to  be  maintained,  and  accuracy  of 
interceptor  control;  and  interfacing  roles  with  sensors,  civil  air  traffic 
control,  early  warning,  strategic,  and  command  systems. 

• Deployment.  Intended  deployment  of  the  system  is  described  in  terms  of 
numbers  and  locations  of  operating  sices  or  installations  and  relation- 
ships with  the  user  organization,  including  mission  responsibilities  of 
organizational  elements  and  primary  functions  to  be  performed  by  each 
element  at  the  specified  locations.  This  information  should  be  based  on 
system  engineering  functional  analyses  directed  cowards  aligning  groups 
of  system  functions  (e.g. , functional  areas  or  system  segments)  with  the 
operating  locations  and  user  organization. 


• Logistic  Support.  The  system  specification  should  summarize  the  require- 
ments Imposed  by  considerations  of  supply,  maintenance,  and  support  faci- 
lities. This  Information  should  Include:  Impacts  on  the  supply  system, 
Witt)  respect  to  such  functions  as  introduction  of  new  Items,  re-supply 
methods,  and  distribution;  levels  of  maintenance  to  be  performed  (organi- 
zational, field,  depot)  and  command  responsibilities;  and  requirements  for 
new  or  uae  of  existing  maintenance  facilities  and  auxiliary  equipment. 


In  tl)e  area  of  operational  functions  and  requirements  for  information  pro- 
cessing aspects  of  a system,  the  pacing  criteria  tend  to  be  matters  of  required 
system  outputs,  which  may  be  In  the  nature  of  control  actions,  decisions, 
orders,  recommendations,  reports,  or  other  Information  to  be  either  used 
directly  by  operational  command  personnel  at  the  system  location  or  transmitted 
to  outside  destinations.  Hence,  much  of  the  conceptual  phase  study  leading  to 
the  system  specification  should  have  resulted  In:  (1)  identifying  those 
outputs  and  defining  cl)elr  associated  performance  requirements  with  respect  to 
such  characteristics  as  accuracies,  completeness,  volumes,  frequencies, 
timeliness,  and  traceability;  and  (2)  deriving  similar  requirements  for 
inputs  and  processing  functions  necessary  to  produce  those  outputs.  Where  a 
large  data  base  is  involved,  the  data  categories  and  files  should  have  been 
identified,  together  with  estimated  volumes,  requirements  for  site  or  oper- 
ating mode  adaptation,  and  special  requirements  for  data  collection  and 
generation.*  This  information  shou....  constitute  prominent  portions  of  tlie 
performance  requirements  specified  in  paragraph  3.2.1  of  the  system  speclfi- 
cat ion. 


Again,  the  level  of  detail  will  notnnally  vary.  Message  inputs/outputs  inter- 
nal to  the  systett-*e.g. , between  system  segments  -mav  often  be  defined  only  tc 
the  extent  of  identifying  their  existence  and  general  nature,  whereas  messages 
input  from  other  existing  systems,  or  required  for  output  to  those  systems, 
may  be  precisely  defined  at  the  level  of  format/content,  timing,  volumes, 
etc.  for  individual  messages.  Subsequent  efforts  during  the  validation  phase 
should  result  In  reducing  all  of  those,  including  data  base  definitions,  to 
the  lowest  level  needed  as  a basis  for  design  (or  in  some  ca-tes,  selection^ 
of  computer  equipment,  consoles,  communications  equipment,  and  computer 
programs. 


*The  term  "data  base"  refers  here  to  data  which  are  of  interest  to  the  user, 
and  which  must  later  be  fully  specified  in  the  development  specifications 
for  CPCls.  It  Is  typically  only  one  portion  of  the  "data  base"  eventually 
specified  for  developed  CPCls  in  their  Part  II  (product)  specifications. 

See  3.14.1  herein  for  a further  discussion. 
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b.  System  Design 


In  order  to  arrive  at  assessments  of  feasibility,  cost,  and  schedule,  much  of 
the  conceptual  phase  effort  is  necessarily  devoted  to  studies  of  design, 
during  which  firm  decisions  are  reached  with  regard  to  the  overall  system 
configuration.  Those  decisions  should  be  arrived  at  through  the  general 
system  engineering  process  of:  analyzing  functions  and  performance  requirements 
for  the  system  as  a whole;  performing  trade-off,  feasibility,  and/or  advanced 
development  studies  to  identify  major  system  segns^nts  and  equipments  and 
allocating  functions  to  those;  determining  design  requirements  and  constraints; 
and  identifying  interfaces  between  segments  and  with  other  systems.  While 
some  significant  design  decisions  are  typically  predetermined  by  policy, 
economic  considerations,  or  other  constraints — e.g. , use  of  a Government- 
inventory  computer , existing  facilities,  or  existing  trained  personnel — , a 
systematic  application  of  that  analytical  process  is  generally  essential  in 
order  to  establish  and  verify  the  technical  integrity  of  the  resulting  configu- 
ration. 


"Design"  aspects  of  the  system  are  expressed  in  the  system  specification  in 
the  form  of  (1)  identifications  of  the  system  elements  and  their  structure 
into  system  segments,  (2)  physical  constraints  such  as  space  or  weight  limita- 
tions, and  (3)  design  and  construction  standards  which  apply  generally  to 
system  equipment  or  computer  programs.  The  system  specification  for  a command, 
control,  and  communications  (C^)  system  should  typically  include  coverage  in 
the  following  areas: 


• Personnel  are  to  be  identified  in  the  form  of  a preliminary  estimate  of 

numbers  and  types  of  personnel  allocated  to  system  operations,  control,  and 
maintenance.  These  estimates  should  take  into  account  the  planned  deploy- 
ment modes,  normal  and  emergency  conditions,  and  intended  duty  cycles. 
Factors  of  organization,  command  levels,  geographic  locations,  and  operator 
positions  should  be  specified  to  provide  a basis  for  subsequent  detailed 
analyses,  during  the  validation  phase,  leading  to  Part  I specifications  for 
mission  computer  programs,  associated  manual  and  man-machine  procedural 
data,  and  expanded  personnel  requirements  information. 


• Data  processing  and  display  equipment  should  generally  be  specified  in 
terms  of  required  functional  characteristics,  at  levels  which  permit 
latitude  for  subsequent  selection,  or  approaches  to  the  design  of,  individual 
items.  The  system  specification  should  incorporate  schematic  block  diagranw 
and  associated  system  engineering  documentation  which  portray  the  logical 
and  physical  equipment  configuration  and  geographic  locations.  Numbers, 
types,  capacities,  and  similar  requirements  should  be  specified  for  the 
central  processor (s) , peripheral  storage  and  input/output  equipment, 
operator  consoles,  and  special  data  displays.  This  Information  is  normally 
subject  to  expansion,  refinements,  and  possibly  some  revisions,  during  the 
validation  phase.  Minimum  design  and  construction  standards  which  apply 
generally  to  system  equipment  are  specified  in  paragraphs  3.3.1  through 
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3.3.7  of  the  system  specification,  e.g.,  for  laaterials,  electromagnetic 
radiation,  workmanship,  safety,  and  human  engineering.  To  Che  extent 
possible,  these  are  specified  by  citing  established  military  standards 
and  specifications. 

e Cosaunications  capabilities  vary  considerably,  among  different  systems, 
as  regards  the  extent  to  which  they  constitute  prominent  elements  of  Che 
system— l.e.,  in  Che  specific  sense  of  whether  they  are  being  developed, 
acquired,  or  laodified  under  Che  given  system  program.  Their  treatment  in 
Che  system  specification  varies  accordingly.  In  the  minimum  case, 
existing  (common  use)  capabilities  are  identified  and  specified  as  system 
interfaces.  To  the  degree  Chat  the  system  program  involves  the  acquisition 
of  specialized  and  dedicated  capabilities,  the  performance,  design,  and  test 
requirements  for  coaminications  hardware  and  software  will  constitute 
correspondingly  prominent  portions  of  the  system  specification  as  a whole. 

a Facilities  are  typically  long  leadtime  items  for  which  concepts  and  require- 
ments should  be  determined  very  early  in  the  program.  The  initial  system 
specification  should  identify  all  facilities  to  be  used,  and  should  specify: 
whether  existing,  or  to  be  modified  or  newly  constructed;  nature  and 
intended  use  (operations,  maintenance,  training);  acquisition  approach 
(military  construction  program,  or  other);  and  required  facility  character- 
istics which  are  essential  to  be  known  as  the  starting  basis  for  validation 
phase  development  of  detailed  requirements  and  planning  for  the  acquisition 
of  other  system  elements,  particularly  for  system  equipment  and  personnel. 
The  detailed  requirements  for  those  other  elements.  In  turn,  should  then 
be  reflected  In  performance-level  specifications  for  facilities  (M1L-STD-49U 
Type  B4)  to  be  completed  during  the  validation  phase. 

e Computer  programs  should  generally  be  Identified  in  the  initial  system 
specification  in  terms  of  types  of  functions  to  be  performed — e.g.,  opera- 
tional, simulation,  maintenance-diagnostic,  and  other  support  functions. 
Specific  Individual  items  may  be  identified  if  they  have  already  been 
selected  or  if  the  identification  is  relatively  obvious,  as  it  might  be, 
for  example,  for  a special  compiler  or  various  other  off-line  computer 
programs.  MlL-STD-483  (Appendix  111)  provides  for  adding  a "design  and 
construction"  subparagraph  (3.3.8)  in  the  system  specification  for  citing 
computer  programming  language  and  other  standards  which  have  general 
applicability  to  all  computer  programs  in  the  system.  In  line  with  the 
expressed  intent  for  paragraph  3.3  as  a whole,  this  subparagraph  should  be 
confined  to  specifying  mlnlaum  standards  which  have  general  applicability, 
making  maximum  use  of  references  to  approved  military  standards  and 
specifications.  In  accordance  with  general  policy  for  the  system  specifi- 
cation, it  should  especially  avoid  imposing  constraints  which  might  unneces- 
sarily limit  the  latitude  of  later  design  solutions. 


Syatem  segments*  must  be  identified  In  the  system  specification,  together 
with  information  in  the  areas  listed  below.  Allocations  of  performance 
requirements,  including  interfaces  with  external  systems,  should  be  relatively 
complete  and , definitive  in  the  initial  system  specification.  Definitions  of 
inter-segment  interfaces  and  identifications  of  configuration  items  are  normally 
subject  to  significant  expansion  and  refinement  as  a result  of  continued  system 
engineering  studies  to  be  conducted  during  the  validation  phase. 


• Each  segment  is  identified,  normally  by  a generic  name  (e.g..  Communica- 
tions Segment,  Command  Center  Segment),  and  system  characteristics  speci- 
fied in  paragraph  3.2  of  the  specification  are  allocated  among  the  segments. 
Allocations  consist  of  (1)  apportioning  some  requirements  to  two  or  more 
segments,  such  that  the  sum  of  the  allocations  is  equal  to  the  total 
requirement,  and  (2)  specifying  requirements  peculiar  to  each  segment.  Tlie 
latter  may  consist  of  system  requirements  specified  in  paragraph  3.2  which 
are  allocated  in  their  entirety  to  the  segment  (usually  by  reference),  plus 
some  requirements  peculiar  to  the  segment  that  may  not  have  been  specified 
for  the  system  as  a wiiole.  Design  and  construction  standards  specified  in 
paragrapli  3.3  of  the  system  specification  are  not  Included  in  those  alloca- 
tions, since  they  apply  to  all  segments. 


• Functional  interfaces  are  identified  for  each  system  segment  and  defined  to 
a level  of  detail  which  is  adequate  to  permit  concurrent  and  compatible 
further  development  of  the  segments  during  the  validation  phase.  Interface 
definitions  are  derived  Jointly  from  the  system  functional  flows  and  alloca- 
tions of  system  functions  to  the  segments,  including  allocations  of  inter- 
faces with  external  systems  when  they  affect  an  individual  segment.  For 
information  processing  elements  of  the  system,  the  most  prominent  interfaces 
to  be  identified  (and  defined  to  the  level  that  they  are  known  at  the  outset 
of  validation)  are  the  message  inputs  and  outputs,  among  segments  and  with 
other  systems. 


• Configuration  items  of  equipment,  facilities,  and  computer  programs  (see 
above)  are  identified  and  listed  for  each  system  segment.  In  the  initial 
system  specification,  these  lists  will  normally  be  provided  in  terms  of 
generic  names  for  the  items  (e.g.,  central  processor),  emphasizing  items  of 
major  significance,  and  will  normally  be  incomplete  with  respect  to  both 
the  identified  items  and  quantities.  At  the  end  of  the  validation  phase, 

Che  lists  should  be  complete  with  respect  to  identifying  nuod>ers,  approved 
nomenclature  of  each  item,  and  quantities  required  for  Che  full-scale  devel- 
opment phase. 


*The  terms  "system  segment"  and  "functional  area"  are  being  used  for  purposes 
of  this  description  as  being  essentially  equivalent.  See  paragraphs  3.1.1 
and  7.3  of  ref.  10  for  a further  discussion  of  these  terms. 
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1.2.2  The  Validation  Phase 


The  validation  phaae  la  characterized  in  AFSCP  800-3  (Chapter  1)  in  the 
following  summary  terms: 

"During  this  phase,  major  program  cliaracterlstlcs  are  validated  and 
refined,  and  program  risks  and  coats  are  assessed,  resolved,  or 
minimized.  A ratification  decision  Is  sought  when  the  confidence 
of  success  and  cost  realism  becomes  high  enough  to  warrant  progression 
to  the  next  phase..." 


Those  are  the  same  objectives  that  were  formerly  attached  to  the  contract 
definition  phase,  prior  to  the  advent  of  current  UoD  SOOO-series  directives 
and  Air  Force  SOO-seriea  regulations.  The  major  difference  is  that  emphasis 
is  now  placed  on  performing  advanced  development  and  prototype  testing,  in 
areas  of  Identified  high  technical  risk,  as  opposed  to  the  former  emphasis 
on  purely-paper  analysis  and  planning.  The  major  overall  goal,  liowever.  Is 
still  to  advaitce  the  definition  of  the  program  as  a whole  to  a level  which 
provides  a sound  and  adequate  starting  point  for  full-scale  system  develop- 
ment. Specific  objectives  to  support  that  goal,  as  outlined  in  AFSCM  800-3 
(Chapter  3)  and  elsewhere,  are  the  following: 

• Establlsli  firm  and  realistic  performance  specifications  (allocated 
baseline)  which  meet  the  operational  and  support  requirements. 


• Accomplish  planning  for  program  office  management  of  the  next  phase; 
release  KFFs;  acquire  and  evaluate  contractor  technical  and  business 
proposals;  and  negotiate  the  full-scale  development  contract (s). 


Current  policy  also  emphasizes  flexibility  In  the  methods,  intermediate 
milestones,  and  approaches  employed  by  program  offices  to  meet  those  gener- 
alized goals.  Each  program  manager  Is  responsible  for  tailoring  the  sequence 
and  content  of  activities  to  meet  the  needs  specified  for  his  program. 


a.  Technical  Risk 

Willie  the  activities  of  harilware  proofing  and  prototype  demonstration  may 
be  indicated  In  some  cases  for  electronic  systems,  the  brief  overview  of  the 
validation  phase  presented  herein  does  not  attempt  to  Include  a description 
of  those.  If  they  should  be  required  In  a given  program,  it  is  assumed  that 
their  primary  purposes  will  be  to  reduce  the  technical  and  cost  risks 
associated  with  entering  Into  full-scale  development  of  the  system  hardware. 


As  stated  In  Air  Force/DoD  policy  documents,  prototype  demonstration  is 
linked  with  the  "f ly-before-you-buy"  principle.  That  principle  does  not 
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clearly  apply  to  a one-of-a-kind  system  for  either  hardware  or  software, 
although  it  might  apply  to  an  electronic  system  to  be  produced  in  quantity, 
or  possibly  in  modified  form  to  a very  large  and  complex  communications 
network. 


Prototype  development  in  the  "fly-before-buy"  sense  is  not  a realistic 
practice  for  software  elements  of  a system,  since  the  quantity  production 
of  a computer  program  does  not  account  for  an  appreciable  part  of  the  total 
expense  of  its  acquisition.  By  the  time  the  performance  of  a computer  pro- 
gram can  be  demonstrated,  chat  particular  computer  program  ims  already  been 
effectively  "bought".  While  it  is  conceivable  that  some  form  of  advanced 
development  Co  reduce  technical  risk  might  apply,  there  are  no  known  examples 
of  cases  in  which  that  approach  would  appear  to  be  realistic — i.e.,  for 
purposes  of  proving  out  the  software  as  such.  Experience  has  demonstrated 
Chat  Che  risks  of  entering  into  full-scale  development  of  software  are  often 
real  and  substantial.  But  it  has  rarely  if  ever  been  indicated  that  the 
problems  encountered  result  from  limitations  in  technical  state-of-the-art. 
Typically,  they  are  matters  of  inadequate  requirements  definition  and 
management  planning. 


Hence,  the  brief  description  provided  below  outlines  a validation  phase  as 
it  might  be  conducted  to  alleviate  chose  latter,  major  problems.  To 
that  end,  it  does  not  attempt  to  address  the  various  complications  whlcl)  are 
necessarily  introduced  if  a given  program  should  also  happen  to  involve 
hardware  proofing  and/or  prototype  demonstration  and  testing. 


b.  Overview  of  Events 

Major  technical  activities  and  events  during  the  validation  phase  are 
depicted  in  Figure  3,  emphasizing  activities  which  would  normally  be  accom- 
plished by  one  or  more  validation  phase  contractors.  The  period  shown  would 
be  preceded  by  a subphase  during  which  KFPs  are  prepared  and  Issued,  contractor 
proposals  prepared  and  submitted,  the  source(s)  selected,  and  contract (s) 
awarded.  It  should  normally  be  followed  by  another  subphase  devoted  to  evalu- 
ation of  products,  negotiation  of  full-kcule  development  contracts,  and 
review  and  decision  by  higher  headquarters. 


Within  the  period  shown,  the  diagram  summarizes  the  following  points: 


• Objectives  during  the  first  part  of  the  contracted  validation  phase  are 
to  analyze  and  expand  the  definition  of  requirements  at  the  system  and 
system  segment  levels,  verifying  system  mission  and  support  functions 
and  refining  their  allocations  to  system  personnel,  facilities,  and 
configuration  items.  This  basic  system  engineering  effort  continues 
throughout  the  phase,  resulting  in  expans ion/ ref inement  of  the  system 
specification  and  supporting  system  engineering  documentation. 
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Figure  3.  Summary  Diagram  of  Validation  Phase  Activities  and  Events.  j 


• Following  the  system  requirements  review  (SKR) , the  focus  of  effort 

shifts  to  developing  detailed  definitions  of  requirements  for  individual 
configuration  items  and  documenting  those  in  the  form  of  development 
(Part  1)  or  other  specifications  appropriate  to  the  type  or  class  of 
each  identified  item. 


• A system  design  review  (SDR)  is  held  as  a final  review  prior  to  submittal 
of  validation  phase  products  to  review  and  assess  their  validity  and 
completeness . 

• The  mainline  technical  effort,  throughout  this  phase,  is  at  the  system 
engineering  level — i.e.,  basically  interdisciplinary,  and  focused  on 
system  compatibility  of  requirements  documented  in  the  Cl  development 
specifications  as  well  as  in  the  expanded  system  specification. 


• Software  and  various  hardware  (component)  engineering  specialists  provide 
essential  inputs  and  support,  and  bear  major  responsibilities  for  design 
studies  upon  which  to  base  plans,  schedules,  and  costs  for  the  ensuing 
full-scale  development  phase. 
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c.  Software  Engineering  During  Validation 


As  indicated  previously  and  discussed  further  below,  the  responsibility  for 
developing  Part  I specifications  for  mission  CPCIs  should  not'  normally  be 
assigned  to  software  engineers.  However,  the  requirements  for  software 
engineering  at  both  technical  and  management  levels  during  a properly-conduc- 
ted validation  phase  are  significant  and  extensive.  Provisions  should  be  made 
for  effort  in  the  following  areas: 

• At  the  outset  of  the  phase,  software  fingineers  should  conduct  studies 
of  computer  program  design  at  the  system  and  system  segment  levels  in 
sufficient  depth  to:  (1)  vontrlbute  to  hardware/software  trade-off 
decisions;  (2)  provide  sizii  g and  tfbting  estimates  as  a basis  for  deter- 
mining computer  and  computer  storage  requirements;  and  (3)  assure  the 
technical  soundness  of  CPCl  Identification/selectlon,  pfior  to  SRR.* 

• The  analysis  of  requirements  for  support  computer  programs,  identifications 
of  support  items,  and  preparation  of  Part  I specifications  for  develop- 
mental CPCIs  in  the  support  area  (e.g.,  compiler  or  other  utility  tools) 
are  matters  for  which  primary  responsibilities  should  also  be  assigned 

to  software  engineers. 

• It  should  be  recognized  that  it  is  usually  necessary  to  develop  a design 
approach  to  each  proposed  CPCl  in  parallel  with  the  development  of  its 
Part  I specification.  While  the  level  is  likely  to  vary,  it  may  be 
indicated  in  some  cases  that  the  design  for  a major  CPCl  should  be  studied 
in  sufficient  depth  to  yield  a first  approximation  to  the  overall  CPCl 
design  to  be  later  reviewed  at  the  preliminary  design  review  (PDR).  Direct 
documentation  of  that  design  shof^d  never  be  Included  in  the  Part  I speci- 
fication; and  it  is  not  clearly  called  for  in  other  deliverable  documents 
at  the  end  of  validation.  However,  the  fact  that  it  has  been  accomplished 
should  be  reflected  in  a variety  of  related  validation  phase  efforts  and 
products.  As  examples: 

(1)  In  support  of  the  Part  I specification  development,  sufficient  design 
studies  should  be  accomplished  to  verify  the  design  feasibility  of  perfor- 
mance requirements,  and  in  some  cases  to  estimate  the  cost-effectiveness 
of  alternative  requirements  being  investigated  by  the  Part  1 specification 
development  team.  a 


'9 

^Failure  to  fully  appreciate  the  fact  that  CPCl  selection  is  an  important 
design  decision,  which  necessarily  orecedes  the  development  of  Part  I 
specif ications,  has  been  a source  of  serious  problems.  See  ref.  10, 
paragraph  2.2. 
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(2)  The  computer  program  development  plan  (CPDI’;  Dl-S-3()567)  and 
formal  CPCl  test  plan  (Dl-T-3703),  jointly,  require  descriptions  of  the 
approach,  metl\odoluKy , schedules,  and  levels  of  manpower  required  during 
full-scale  development  for  CPCl  design,  development,  and  testing.  To 
be  realistic,  that  planning  must  be  based  on  preliminary  information  in 
such  areas  as  the  CPCl  structure  into  CPCs,  allocations  of  functions  to 
CPCs,  the  planned  sequencing  of  CPC  coding  and  assembly,  and  sixing 
estimates  for  individual  CPCs.* 


d.  Development  of  the  CPCl  Part  1 Specification. 

It  has  been  stated  above  that  development  of  the  Part  I specif icatlon  for  a 
mission  CPCl  is  a svstem  engineering  activity.  As  such,  it  is  not  a process 
for  which  specific  approaches  and  techniques  are  prescribed  in  any  current 
standards.  That  situation  exists,  in  part,  because  of  the  inherent  diffi- 
culties involved  in  standardixing  management  procedures  for  technical 
development — particularly  at  the  levels  which  demand  creative,  new  products — 
and  in  part  because  it  is  Air  Force  policy  to  emphasize  control  of  the  tech- 
nical aspects  of  a system  program  at  the  level  of  objectives  and  general 
procedures,  as  opposed  to  detailed  methodologies. 


At  a general  level,  the  process  for  a mission  CPCl  can  be  described  as  one 
of:  progressively  Identifying  tlie  system  functions  and  subfunctions  allocated 
to  tiie  CPCl;  examining  mission  requirements  and  modes  of  operational  usage; 
performing  trade  studies  (among  functional  alternatives)  and  time  line 
analvses  when  indicated;  aiid  establishing  detailed  performanv'e  requirements 
for  each  function  ttnd  subfunction.  A few  characteristics  and  rules  which  can 
be  stated  for  that  process  are  summarized  as  follows:  > , 

• The  analyst's  direct  purpose  is  to  develop,  verify,  and  document  detailed 
requirements  for  the  mission  computer  program,  at  the  levels  described  in 
Section  3 of  this  guidebook.  In  the  course  of  that  activity,  however,  he 
must  also  develop  and  verify  detailed  requirements  for  manual,  man-machine, 
and  equipment  functions  associated  with  that  computer  program.  His  (or 
their)  Job  includes  assuring  tliat  requirements  and  plans  for  command 


♦Those  plans  should  not  normally  be  approved  by  the  procuring  activity 
until  they  are  later  updated  and  expanded  to  reflect  the  results  of  a 
successfully-completed  PDR.  Even  then,  "approval"  should  be  confined  to 
acceptance  of  their  delivery  against  the  CDRL  and  acknowledgement  of  their 
compliance  with  requirements  of  their  respective  DlDs.  As  for  the  tech- 
nical design  reviews  themselves,  procuring  activity  acknowledgement  of 
compliance  should  be  accomplished  in  a manner  which  does  not  constitute 
approval  of  the  design  as  such  (see  Section  6,  "Notes",  in  MIL-STD-1521A) . 
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uctluns,  operator  procedures,  and  manual  or  automatic  Input/output  devices 
are  ail  fully  Integrated  with  requirements  for  the  computer  program 
operation. 

• i)ne  technique  which  has  been  found  useful  is  to  develop  and  document  a 
series  of  scenarios  ("operat lonal  system  description")  detailing  each 
step  and  event  for  each  mode  of  mission  operation— 'and  to  ask  the  questions 
of  WItat , How,  When,  How  Urgent,  etc.  associated  with  each  step,  iterating 
tl»at  process  until  the  questions  are  resolved  and  the  neceitjary  level  of 
definition  has  been  reached.  These  and  related  system  engineering  docu- 
ments— e.g. , in  the  form  of  functional  flow  block  diagrams,  time  line  or 
trade  study  reports,  and  requirements  allocation  sheets — function  primarily 
as  interim  working  tools,  which  aid  In  developing  and  verifying  the 
requirements  and  other  information  to  be  documented  separately  in  the  CPCl 
Part  I specification,  inputs  to  the  expanded  system  specification  and 
development  specifications  for  equipment  items,  and  operator  task  analysis 
data. 


• To  perform  those  tasks  effectively,  the  analyst's  major  orientation  is 
necessarily  towards  the  user's  mission  operations.  His  real  concern  is 
to  develop  a progressively-detailed  definition  of  liow  those  operations 
will  be  supported  l)y  automated  functions,  and  to  continually  evaluate 
the  results  from  that  point  of  view. 

• That  process  should  start  with  the  assurance  that  it  is  feasible  Co  design 
a computer  program  which  will  perform  functions  within  the  given  general 
scope,  based  on  system-level  design  studies  completed  prior  to  SRR;  and  It 
should  be  supported  by  further  assessments  of  design  feasibility  performed 
by  software  engineers  for  tlie  given  CPCl  (see  1.2.2,c),  ns  necessary  during 
the  process.  Hut  the  mainline  activity  of  the  Part  I specification 
developers  should  otherwise  largely  Ignore  matters  of  computer  program 
design,  in  the  interests  of  formulating  a comprehensive  and  definitive 
statement  of  user/procur ing  activity  requirements. 


Thus,  while  the  approach  and  techniques  required  to  develop  the  Part  I speci- 
fication for  a CPCl  may  be  characterized  as  being  those  of  system  engineering, 
because  they  Involve  multiple  disciplines  and  inultlplc  classes  of  system 
components,  it  also  tends  to  be  true  that  the  major  and  generally  indispens- 
able ingredient  is  the  matter  of  expertise  in  the  user's  operational  functions. 
In  general,  the  focal  concern  of  the  analysis  team  must  be  with  the  detailed 
Information  processing  needs  associated  with  those  operational  functions — 
wtiether  they  be  air  defense,  tactical  operations,  weapons  control,  space 
communications,  interstellar  navigation,  configuration  management,  petroleum 
refining,  or  automated  rapid  transit. 


By  providing  a more  expanded  description  of  proper  content  for  tlie  completed 
specification  than  has  previously  been  available,  this  guidebook  is  intended 
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to  help  alleviate  one  factor  in  the  difficulties  which  procuring  activities 
have  encountered.  It  is  a matter  of  experience  that  a good  Part  I CPCI 
specification  is  relatively  rare — good,  that  is,  in  the  sense  that  it  actually 
contains  the  scope  and  levels  of  information  specified,  and  provides  a sound 
basis  for  initiating  development  of  the  CPCI.  While  it  is  hoped  that  the 
situation  will  be  improved  through  better  guidance  and  training  in  wliat  the 
specification  should  contain,  there  are  other,  related  factors  which  should 
also  be  recognized  as  important  contributors  to  the  prevalent  difficulties. 

A few  of  those  are  identified  in  the  following  comments. 

• Requirements  definition  for  a complex  operational  computer  program  is  a 
tedious  and  time-consuming  task,  which  results  in  nothing  immediately 
visible  except  paper.  To  be  performed  properly,  it  requires  high  priority 
emphasis  on  the  part  of  top-level  management  to  provide  the  qualified 
operational/system  engineering  personnel,  adequate  funding,  time,  and  firm 
insistence  upon  a satisfactory  product  before  permitting  a system  program 
to  proceed  further  downstream.  Those  conditions  rarely  if  ever  exist;  and 
t)iey  are  not  likely  to  exist  until  a validation  phase,  or  equivalent  effort, 
is  planned,  scheduled,  and  funded  for  that  specific  purpose. 

• There  is  a widespread  tendency  to  assume  that  Part  1 CPCI  specifications 
should  be  prepared  by  software  engineers — since  they  are,  after  all, 
specifications  for  computer  programs.  However,  as  outlined  above,  they 
are  specifications  primarily  of  what  the  CPCI  must  accomplish  for  the 
user,  not  of  how  the  computer  program  is  to  be  designed  and  coded.  By 
training  and  interest,  the  software  engineer  is  naturally  focused  on  the 
latter — often,  grossly  at  tl»e  expense  of  the  former.  Wi>lle  there  are 
exceptions — e.g. , where  the  software  engineer  l>as  acquired  adequate  knowl- 
edge of  user  requirements  through  experience  in  the  given  applications 
area — the  more  frequent  result  is  a long  and  costly  "evolutionary"  process 
through  which  the  initially-developed  CPCI  may  eventually  become  reconciled 
with  the  user's  actual  needs. 


• System  engineering  is  often  thought  of  as  a single,  structured  discipline 
■\g  its  own  body  of  technical  knowledge,  tools,  and  techniques.  While 
. is  true  to  a degree,  the  concept  is  also  subject  to  significant 
qualifications.  Existing  system  engineering  approaches  and  techniques 
have  evolved  and  become  known  principally  in  the  working  environments  of 
aircraft  and  missile  systems.  Relatively  little  effort  has  been  devoted 
to  adapting,  documenting,  and  applying  those  or  similar  techniques  to  the 
information  processing  elements  of  C^  systems.  Thus,  the  generallzable 
system  engineering  technology  required  to  support  the  development  of  Part 
I CPCI  specifications  is  relatively  undeveloped;  and  that  limitation  is 
further  aggravated  by  the  typical  need,  if  the  techniques  are  to  be  truly 
effective,  to  combine  their  application  with  intimate  knowledge  of  the 
specific  military  operations  to  be  performed  by  the  given  system. 
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SECTION  2.  GENERAL  GUIDELINES 


Th«  purpose  of  this  section  is  to  sumnarize  a few  considerations  and  rules 
which  apply  to  the  development  specification  as  a whole,  affecting  the 
preparation  and  evaluation  of  all  sections/paragraphs  discussed  individually 
in  the  following  section  (Section  3). 


2.1  NOTES  ON  SPECIFICATION  EVALUATION 

a.  As  discussed  here,  "evaluation"  of  a CPCI  Part  1 specification  is  the 
process  of  reviewing  and  assessing  a prepared  specification  for  compliance 
with  its  preparation  requirements,  as  a basis  for  approval,  authentication, 
and  baselining  for  configuration  control.*  Preliminary  evaluation  of  the 
partially-completed  specification  should  occur  at  the  SDR,  late  in  the 
validation  phase  (see  Appendix  B of  MIL-STD-1521A) . Formal  evaluation  at  the 
end  of  the  validation  phase  should  be  conducted  in  accordance  with  the  policies 
and  guidelines  set  forth  in  Chapter  2 of  AFSCM/AFLCM  375-7. 


b.  The  evaluation  process  for  a Part  1 specification  does  not  Involve  a 
formal  audit,  comparable  to  the  physical  configuration  audit  which  is  held 
to  verify  the  adequacy  of  a Part  II  specification.  It  is  normally  conducted 
by  an  in-house  specification  review  team,  chaired  by  the  procuring  activity's 
configuration  manager.  As  appropriate  to  the  system  and  CPCI,  the  team  may 
consist  of  members  representing  engineering  and  support  management  activities 
of  the  program  office,  not-for-profit  contractor,  AFLC,  and  the  using  command. 
Following  coordination  of  in-house  comments,  a last  phase  of  the  review  may 
be  held  at  the  contractor's  facility  with  participation  by  corresponding 
contractor  personnel. 


c.  Thus,  that  pattern  provides  for  a comprehensive  review  of  the  specifica- 
tion with  respect  to  its  many  significant  aspects,  reflecting  the  same 
variety  of  technical,  management,  user/operational,  and  support  skills  and 
Interests  which  should  have  been  represented  in  the  specification's  prepara- 
tion. The  approach  taken  by  individual  evaluators,  and  the  Importance  of 
different  aspects  of  the  specification,  will  vary  accordingly.  As  examples: 


*Tho8e  terms  associated  with  the  process  are  often  used  as  being  inter- 
changeable. Distinctions  based  on  the  order  in  which  events  occur  can  be 
useful,  however,  as  follows:  Evaluation,  when  its  results  are  favorable, 
leads  to  approval , which  signifies  acceptance  of  the  preparation  activity's 
delivery  of  the  specification  (l.e. , as  a CDRL  item).  Authentication 
occurs  when  the  program  manager's  signature  is  affixed  to  the  specification 
title  page;  and  the  specification  is  baselined  for  configuration  control, 
by  the  configuration  management  office,  as  a result  of  authentication. 
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• Emphasis  in  the  system  engineering  evaluation  will  typically  be  placed  on 
examining  the  completeness  and  integrity  of  detailed  functional  descrip- 
tions, interfaces,  and  data  base  definitions  contained  in  Section  3.  The 
primary  objective  of  this  evaluation  is  to  verify  (as  well  as  it  can  be 
done,  analytically)  that  the  CFCl,  when  later  qualified  against  the  speci- 
fied performance,  will  indeed  satisfy  the  system  requirements. 

• Software  engineers  should  examine  the  entire  specification  carefully  from 
the  point  of  view  of  its  implications  for  computer  program  design,  with 
attention  to  such  factors  as  feasibility,  design  requirements/constraints, 
and  adequacy  of  information  needed  to  govern  the  subsequent  CPCI  develop- 
ment and  testing.  An  import. tnt  objective  of  the  specification  is  to 
minimize  the  need  for  computer  programmers  to  conduct  further  research 
into  system  requirements,  during  the  course  of  their  development. 

• Configuration  and  data  managers  should  evaluate  the  specification  for 
compliance  with  standards  for  its  format  and  content,  including  attention 
to  considerations  in  such  areas  as  organization,  style,  security,  identi- 
fying numbers  and  nomenclature,  specification  maintenance,  and  precision/ 
clarity  of  the  stated  requirements  for  purposes  of  conf iguratlr>n  control. 


d.  This  guidebook  is  designed  to  present  improved  criteria  for  Judging  whether 
the  specification — i.e.,  any  CPCI  Part  I specification,  in  general — contains 
information  in  the  required  areas  and  at  the  proper  level  of  detail.  In  that 
respect,  it  should  provide  an  Initial  "screening"  aid  for  use  by  those  various 
evaluators  in  determining  whether  a given  specification  meets  requirements 
imposed  by  the  CDRL. 


e.  For  reasons  outlined  in  the  preceding  section,  the  situation  encountered 
most  often  is  the  one  in  which  the  specification  is  prepared  without  benefit 
of  sufficient  or  appropriate  system  engineering  analysis  and  total  effort. 
Assuming  that  it  does  address  the  proper  general  subject  matter — i.e., 
functional/performance  requirements  vs.  design — common  results  are  (a)  an 
overall  absence  of  specific  and  detailed  information  in  the  specification 
itself  and  (b)  a dearth  of  supporting  system  engineering  documentation. 

With  regard  to  the  specification  itself: 

• One  very  gross  index  which  merits  further  study  is  a simple  page  count  of 
the  Part  1 specification  in  relation  to  estimated  number  of  instructions 
in  the  CPCI.  The  author  made  this  comparison  using  data  which  happened  to 
be  available  for  eight  system  programs,  among  which  three  were  relatively 
successful  and  five  encountered  serious  problems.  For  the  three,  the  count 
of  Part  I specification  pages  per  1000  eventual  instructions  (assembly) 
ranged  from  18  to  25.  For  the  five,  the  same  count  ranged  from  something 
less  than  1 up  to  a high  of  S. 

• More  direct  indicators  (but  clearly  factors  affecting  the  total  page 
count)  are  provided  by  examining  the  content  of  input,  output,  and  data 
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base  paragraphs  of  che  specification.  These  often  consist  of  little 
iBore  than  brief  narrative  statements  describing  the  general  nature  of  the 
data,  with  little  or  no  detail  specifying  each  data  eleownt  at  the  levels 
required  by  the  preparation  instructions. 


2.2  SOURCE  REQUIREMENTS  AND  CONVENT*.,WS 

While  the  primary  source  of  direct  Instructions  for  the  CPCI  Part  I speci- 
fication format  and  content  is  Appendix  VI  of  MIL-STD-483,  some  of  the 
general  requirements  governing  specifications  set  forth  in  other  Government 
documents  and  elsewhere  in  MIL-STD-483  also  apply.  Principally,  those 
consist  of  requirements  in  the  following  areas: 

e Specification  Identification  and  Style.  MIL-STD-490,  paragraph  3.2,  is 
the  basic  source  of  rules  for  identifying  numbers,  general  format,  and 
style — covering  conventions  to  be  observed  in  such  areas  as  language 
style,  abbreviations,  symbols,  paragraph  identification,  figures,  tables, 
footnotes,  definitions,  and  use  of  references.  Air  Force  specifications 
must  also  comply  with  supplementary  requirements  for  title  pages  speci- 
fied in  paragraph  3.4.9  and  Figure  I of  MIL-STD-483. 


• Security  ^^arkings.  Specifications  containing  classified  Information 
must  be  marked  and  handled  in  accordance  with  security  regulations 
specified  in  the  Industrial  Security  Manual  for  Safeguarding  Classified 
Information,  DoD  5220. 22-M. 


• Multiple-Volume  Specifications.  Specific  Instructions  for  preparing  the 
CPCI  specification  in  the  form  of  a document  series  (multiple  volumes) 
are  not  contained  in  Appendix  VI  of  MIL-STD-483,  but  are  provided  directly 
in  the  data  item  description,  DI-E-3119A.  Implications  for  the  use  of 
that  option  are  further  discussed  in  2.3,  below. 


2.3  SPECIFICATION  STRUCTURE  AND  OUTLINE 
2.3.1  General  Preparation  Keguirewents. 


(From  Block  10  of  Ul-[-J119A) 

1.  The  contractor  shall  prepare  a development  specification  for  each  CPCI  in  accordance  with 
the  requirements  of  M1L-STD*483,  Ap:)endix  VI,  as  stated  in  the  contract  or  work  statement. 

When  otlier  than  Form  la  specifications  are  called  out  in  Block  16  of  the  CORL,  Appendix  VI  of 
M1L-6TD-483  will  be  used  as  a quide  in  the  preparation  of  the  specification,  employinq  the 
specific  form  from  HIL-S-834'JO  which  is  set  fortti  in  Block  16  of  the  CDRL.  The  specification 
cover  page  shall  be  in  accordance  with  f1IL-ST0-4a3,  Figure  1. 

For  convenience  in  describing  the  minimum  essential  content,  the  paragraphs  outlined  in 
Appendix  VI  of  MIL-STO-483  (USAF)  are  arranged  in  a format  which  might  apply  if  the  specifi- 
cation were  to  be  issued  as  a single  document.  However,  the  specification  material  required 
for  a large  information  system  is  typically  too  comfilex  and  bulky  to  be  published  and  distri- 
buted physically  in  one  bound  volume.  In  this  case,  the  material  shall  be  arranged  in 
separate  volumes  corresponding  to  individual  functions  or  as  determined  by  mutual  agreement 
between  the  contractor  and  procuring  activity  to  meet  the  requirements  of  a particular  system. 
At  least  one  volume  of  the  series  shall  utilize  the  complete  format  and  content  to  define  the 
performance,  design,  and  qualification  requirements  for  the  Cl  as  a whole. 


Instructions  to  be  noted  In  the  first  paragraph  above  arc  the  following: 


• Preparation  of  the  specification  must  follow  the  detailed  format/content 
instructions  provided  in  Appendix  VI  of  MIL-STD-483  (specifically,  para- 
graph GO. 4). 


• The  second  sentence,  referring  to  other  than  Form  la  specifications,  is 
meaningful  only  when  it  is  confirmed  and  amplified  by  special  instruc- 
tions provided  in  the  contract  statement  of  work.  As  yet,  there  is  no 
uniform  guidance  available  for  the  application  of  other  than  Form  la  speci- 
fications to  computer  programs  (cf.  reference  10,  paragraph  3,3.1). 


• Cover  pages  must  comply  with  both  Figure  1 of  MIL-STU— 490  and  Figure  1 of 
MIL-STD-4d3,  The  latter  adds  the  significant  requirement  for  authenticating 
signatures.  For  cover  page  identification  of  volumes  and  appendices  of  a 
specification  Issued  as  a document  series,  see  Note  2.3.2,d  below. 


The  second  paragraph  of  the  instructions  provides  for  preparation  of  the 
specification  as  a set  of  separately-bound  volumes.  Note  the  phrase,  "... 
mutual  agreement  between  the  contractor  and  procuring  activity...",  which 
indicates  that  the  list  of  volumes  and  appendices,  bv  number  and  title,  should 
be  prepared  and  submitted  by  the  developer  for  procuring  activity  concurrence 
at  an  early  stage  of  planning.  General  guidelines  are  provided  in  2.3.2  below. 
The  actual  structure  in  each  case  should  be  examined  primarily  from  the  point  of 
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view  of  efficient  use  and  maintenance  of  the  completed  specification.  Sound 
planning  should  also  result  in  a volume  structure  which  corresponds  with  a 
manageable  division  of  technical  responsibilities  for  its  Initial  development. 


2.3.2  Guidelines  for  Volume  Structure. 

Figure  4 summarizes  general  rules  to  be  considered  in  planning  the  structure 
of  volumes  and  appendices  for  a large  and  complex  CPCI.  Related  considera- 
tions are  amplified  in  the  following  notes. 


a.  General  Volume.  An  appropriate  number  and  title  for  the  volume  mentioned 
in  the  DI-E-3119A  instructions  is  "Volume  1,  General".  This  volume  must  con- 
tain the  full  set  of  format  elements  identified  in  MlL-STD-483  (l.e.,  numbers 
and  titles  of  sections,  paragraphs,  and  major  subparagraphs),  plus  additional 
subparagraptis  required  by  content  of  the  given  specification. 

Ail  requirements  pertaining  to  the  CPCI  as  a whole  are  specified  directly  in 
this  volume,  except  for  (a)  classified  material  which  may  be  provided  in  a 
separate  supplement  for  the  purpose,  or  (b)  detailed  definitions  of  messages 
or  common  data  base  items.  Detailed  requirements  pertaining  to  ttiose,  and  to 
individual  functions  covered  in  other  volumes,  are  specified  in  Volume  1 by 
referencing  the  appropriate  other  volume  or  appendix.  Section  4,  Quality 
Assurance,  should  normally  be  provided  completely  in  Volume  1. 


D.  Other  Volumes.  A separate  volume  may  be  devoted  to  one  or  more  major 
functions  to  detail  input,  processing,  and  output  requirements  for  the  indi- 
vidual functions  or,  when  indicated,  by  subfunction.  Each  such  volume  must 
follow  the  Section  1 througii  10  breakdown,  including  the  numbers  and  titles 
of  all  paragraphs  specified  in  MIL-STD-483  which  apply  to  the  given  volume. 
Sections  or  paragraphs  "not  applicable"  to  the  given  volume  are  so 
indicated. 


c.  Appendices . Separately-bound  appendices  may  be  used  to  provide  classi- 
fied supplements  or  common  data  definitions,  includir.g  inputs/outputs  and 
detailed  interface  definitions  (e.g.,  message  formats).  With  the  exception 


*Decisions  in  this  area  also  relate  directly  to  the  matter  of  acliievlng 
"visibility"  during  development.  Waen  the  structure  of  data  processing 
functions  to  be  implemented  by  a given  developer  is  in  fact  large  and  complex 
use  of  the  multi-volume  option  is  a much  sounder  approach  to  achieving 
visibility  of  individual  functions  (and  of  CPCs,  at  the  product  level)  than 
that  of  forcing  an  artifical  breakout  into  many  small  CPCIs  (cf.  reference 
10,  paragraph  2.2). 
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of  paragraph  numbers  (see  Note  e below),  the  format  of  each  appendix  Is 
optional;  It  should  be  designed  to  suit  the  purpose  and  content  of  each 
appendix. 

Note  that  all  information  contained  In  separately-bound  volumes  or  appendices, 
with  Che  exception  of  any  Section  b.  Notes,  Is  an  integral  part  of  the  speci- 
fication and  contractually  binding.  Hence,  an  appendix  Is  not  a suitable 
form  for  recording  derivations,  discussions  of  alternatives,  or  procedures 
for  the  CPCl  operation  and  use. 


d.  Title  Pages.  A volume  or  appendix  number  and  title  must  be  provided  on 
Che  title  page  of  each  volume  or  separately-bound  appendix  In  addition  to  Che 
Identifying  information  illustrated  in  figure  1 of  MlL-STD-483.*  Volumes  are 
numbered  in  Arabic  numerals,  beginning  with  "1";  appendices  are  numbered  In 
Roman  numerals,  beginning  with  "I".  Example: 

COMPUTER  PROGRAM  DEVELOPMENT  SPECIFICATION 

FOR 

SEEK  DUSK  INTERFACE  COMPUTER  PKOGRAK 
CPCl  No.  CG41609 

Volume  10.  RECORDING  AND  DATA  REDUCTION 
[or:  Appendix  III.  TACC  MESSAGE  FORMATS] 


e.  Appendix  Paragraph  Numbers.  Within  each  appendix,  the  first  element  of 
all  paragraph  or  subparagraph  numbers  is  the  appendix  number  converted  to 
Arabic  numerals  and  multiplied  by  10.  For  Illustrations,  note  the  numbering 
of  paragraphs  throughout  the  appendices  of  MIL-STD-483  and  NIL-STD-490,  both 
of  which  conform  with  the  requirements  that  apply  generally  to  specifications. 


Figure  3 Illustrates  one  outline,  adapted  from  an  actual  case,  of  the  type 
wliich  should  be  constructed  at  an  early  stage  In  planning  Che  structure  of  a 
multi-volume  specification. 


*RequiremenC8  for  a "Computer  Program  Identification  Number  (CPIN)"  are 
mentioned  in  AFR  800-14,  Volume  11  (paragraph  6-S).  As  yet,  no  specific 
instructions  for  AFSC  uses  of  chat  number  are  known  to  have  been  issued. 
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CONTENT  REQUIREMENTS  VOLUME  1 - GENERAL  VOLUMES  2 - n APPENDIXES 


Figure  4.  Outline  Guide  for  Structuring  the  Part  1 CPCI  Specification  Content  Into  Volunea  and  Appendices 


OUTLINE  OF  VOLUME/APPENOIX  STRUCTURE 
for 

System  4XXL  Mission  Computer  Program  (MCP) 


Volume  1,  GENERAL 

• Sections  1 and  2 

• Paragraph  3.1  - complete  for  the  MCP 

• Paragraphs  3.2.1  through  3.2.3  - general  level  coverage  of  MCP  functions 

• Paragraph  3.2.4  - complete  coverage  of  Special  Requirements 

• Paragraphs  3.3  and  3.4  - (3.3)  general;  (3.4)  complete  for  the  MCP 

• Section  4 - complete  for  the  MCP 

• Sections  5 and  6 


Volume  2.  SURVEILLANCE  FUNCTIONAL  ELEMENT 

• Sections  1 and  2 

• Paragraph  3.2.1,  Surveillance  Function 

• Paragraph  3.2. 1.1,  Sensor  Data  Processing  Subfunction 
a Paragraph  3.2. 1.2,  Track  Initiation  Subfunction 

• Paragraph  3.2. 1.3,  Track  Management  Siibfunction 
a Paragraph  3.2. 1.4,  Identification  Subfunction 

a Section  6,  Notes 

Volume  3,  MISSION  CONTROL  FUNCTIONAL  ELEMENT 
a Sections  1 and  2 

a Paragraph  3.2.2,  Mission  Control  Function 
a Paragraph  3. 2. 2.1,  Weapons  Guidance  Subfunction 
a Paragraph  3. 2. 2. 2,  Air  Traffic  Control  Subfunction 
a Paragraph  3.2.2. 3,  Mission  Aircraft  Communications  Subfunction 
a Section  6,  Notes 

Volume  4,  COMMAND  FUNCTIONAL  ELEMENT 

a Sections  I and  2 
a Paragraph  3.2.3,  Command  Function 
a Paragraph  3.2.3. 1,  Command  Support  Subfunction 
a Paragraph  3. 2. 3. 2,  Mission  Management  Subfunction 
a Section  6,  Notes 

Appendix  1,  CLASSIFIED  SUPPLEMENT 

a Paragraph  10  - supplement  to  paragraphs  3. 2. 1.3  and  3. 2. 2. 3 

Appendix  11,  INTERFACE  MESSAGE  CONTENTS  AND  FORMATS 

a Paragraph  20  - supplement  to  paragraphs  3. 1.1.2,  3.2.x.y.l,  and  3.2.x.y.3 

Appendix  III,  ADAPTATION  DATA 

a Paragraph  30  - data  base  supplement  to  inputs  paragraphs,  3.2.x.y.l 

Appendix  IV,  WEAPONS  CHARACTERISTICS 

a Paragraph  40  • data  base  supplement  to  inputs  paragraphs,  3.2.x.y.1 

Appendix  V.  COORDINATE  CONVERSION  AND  TRANSFORMATION  EQUATIONS 

a Paragraph  50  - supplement  to  paragraph  3. 2. 1.1,  Sensor  Data  Processing 


Figure  S.  Saaple  Outline  of  the  Voluue/Appendix  Structure 
for  a CPCI  Part  1 Specification. 
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SECTION  i.  CONTENT  UUDANCE 


Tha  Intsnt  of  this  ssctlon  Is  to  provide  Kuliielluss  which  csii  ho  used  by  both 
Air  Force  snd  coutrsctor  personnel  In  clertfytnit  requirements  for,  preperlnj?, 
und  evsluatlng  s computer  proitrsw  development  (I'srt  1)  sped  f lest  Ion  s^tslnst 
the  Instructions  provided  tor  thst  specification  In  Appendix  VI  of  MlL-STD-483 
(USAK).  To  that  end,  the  tollowlnj;  subsections  are  orKsnlced  to  correspond 
with  successive  portions  of  those  MIL-STD-A83  Instructions,  and  to  provide 
Information  In  the  folluwlnit  cateitorlea  (as  applicable  to  each  portion): 

a The  M11.-STIV-A8)  Instructions  pertaining  to  the  );lven  section  or  para- 
sraph(s).  Those  Inst rvu't Ions  are  copied  verbatim  1 rom  the  source  and 
provided  In  a box  Inmedlatelv  below  each  subsect loit  title. 

e An  analvsis  and  exphtnat ion  of  the  Instructions. 

e Notes  IdenC  1 fvliitt  altentatlve  Int  erpret  at  Ions  , techniques,  and'or 
common Iv-encountered  problenus. 

e Examples  lllust  rat  injt  proper  or  alternative  ways  v>f  stating  Cl'Cl 

requirements  In. the  sped f (cat  ion.  i 

Examples  are  drawn  t rom  a number  of  actual  sped  1 1 cat  Ions , nx'dlfled  to 
eliminate  classified  elenieitts  and/or  to  Improve  their  unders  t andab  1 1 1 1 v out 
of  context.  Thev  are  necessarily  limited  with  respect  to  (a)  covorane  of  the 
manv  different  wavs  In  which  information  under  the  ma.for  parattraphs,  in 
particular,  amy  be  oritanlzed  aird  presented,  and  (b)  their  ability  to  illus- 
trate essential  Interdependencies  amon^  the  various  paraftr.iphs  which  would 
exist  in  any  properlv-prepared , single  specification. 

This  ^uldance  is  based  on  tlie  premise  that  the  MlL-STl>-s83  Instructions  for 
preparation  of  the  Tart  I Ol’Cl  specification  are  well  conceived  and  eminently 
sound  In  relation  to  needs  and  circumstances  of  the  system  acquisition 
environment.  A few  imtdlf Icat Ions  arc  recorjmended  In  the  text.  In  the  form  of 
suggested  CURL  backup  Instructions  for  general  application.  However,  those 
are  generallv  matters  of  secondary  significance  which  are  designed  to  amplltv 
and  reinforce,  tather  than  change,  tlie  clear  intent  of  the  instructions  as 
a whole. 
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3.1  SECTION  1,  SCOPE 


1.1  Identificdtion.  This  paragraph  shall  contain  the  approved  identification,  nomenclature, 

and  authorfzeJ'ab'Freviat ion  for  the  computer  program.  This  section  of  the  Cl  specification  i 

shall  begin  with  the  following  opening  phrase:  "This  part  of  this  specification  establishes  i 

the  requirements  for  performance,  design,  test,  and  qualification  of  a computer  program  j 

identified  as  (insert  nomenclature  and  configuration  item  number).  This  CPCl  is  used  to  j 

(provide)  (accomplish) 

1.2  Functional  sumMry . This  paragraph  shall  contain  a summary  of  the  purpose  of  the  speci- 

fication  and  aTri'ef  MScription  of  the  overall  computir  program  by  major  functions  (tasks).  , 

It  shall  further  identify  and  summarize  the  specification  content,  composition,  and  intent. 


3.1.1  General 

Section  1 Is  to  be  written  in  a predominantly  Informational,  rather  than 
directive,  style.  While  the  Information  should  be  presented  concisely, 
additional  material  following  the  specified  opening  phrase  should  be  provided 
as  necessary  to  fully  inform  the  reader  of  relevant  facts  in  at  least  the 
following  areas: 

• The  CPCl  Intended  use,  including  any  peculiar  conditions  or  circumstances 
of  general  Interest  and  significance  pertaining  t'  its  use  or  development. 


• The  CPCI's  major  functions,  described  briefly  in  terms  which  are  meaningful 
and  informative  to  the  Intended  CPCl  users. 


e The  organization  and  coverage  of  information  provided  in  the  specification. 
This  part  should  include  a statement  that  it  is  written  to  comply  with  (as 
applicable):  Appendix  VI  of  MlL'STD-483  (USAF);  the  data  item  description, 
DI-E-3119A;  and  backup  instructions  pertaining  to  this  specification 
provided  with  the  CDRL,  identifying  any  particular  backup  Instruction 
which  might  affect  significantly  the  manner  in  which  the  specification  is 
organized. 

• If  the  specification  is  organized  into  multiple  volumes:  (a)  List,  in 
paragraph  1.2  of  the  general  volume,  all  volumes  and  appendices  of  the 
specification  by  number  and  title;  explain  any  special  rules  on  which  the 
volume  structure  is  based;  and  summarize  what  parts  of  the  total  specifi- 
cation are  covered  in  this  volume.  (b)  In  each  other  volume  or  separately- 
bound  appendix,  reference  the  Scope  section  of  the  general  volume  and 
summarize  the  organization  and  coverage  of  Information  provided  in  the 
given  volume  or  appendix. 
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3.1.2  Note  on  Specifying  CPCl  Types 


In  some  systeiss,  the  requirement  exists  to  adapt  a given  CPCI — i.e.,  alter 
its  configuration  in  relatively  minor  ways.  Including  adaptation  data  to  be 
contained  in  its  fixed  data  base — for  effective  use  at  a number  of  different 
site  locations,  or  perhaps  for  other  multiple  but  closely-related  applica- 
tions. In  such  cases,  the  CPCI  may  be  Identified  as  consisting  of  several 
"types",  corresponding  to  the  number  of  different  configurations  to  be 
provided.  All  such  types  must  be  identified  and  defined  precisely  in  the 
CPCI  specification  at  both  the  development  and  product  levels.  The  employ- 
ment of  the  type  classification  is  one  option,  among  others,  that  should  have 
been  evaluated  and  determined  during  the  process  of  initial  configuration 
item  selection  for  the  system  (see  reference  10,  paragraph  2,3). 


General  requirements  for  specifying  types  and  other  subordinate  classifica- 
tions (addressed  primarily  to  specifications  for  equipment  and  materials) 
are  set  forth  in  paragraphs  4.1.2  and  4.3,b  of  MIL-STD-490.  The  term  "type" 
is  used  here  for  convenience;  other  terms  may  be  used  if  they  better  describe 
the  kind  of  distinction  being  made  in  a given  case  (see  4. 1.2. 1.6  of  MIL-STIV 
490).  In  specifying  types  for  CPCIs,  suggested  rules  are  as  follows: 

e Provide  an  additional  paragraph  in  Section  1,  entitled  "Classification", 
beginning  with  an  opening  phrase  similar  to  the  following:  "The  (nomen- 
clature of  the  CPCI,  or  abbreviation  identified  previously  in  the  first 
paragraph)  shall  be  of  the  following  types,  as  specified:"  That  statement 
is  followed  simply  by  a listing  of  the  designated  types. 

s In  any  paragraph  or  subparagraph  of  Section  3 of  the  specification  which 
involves  differentiating  requirements  for  the  individual  types:  (a)  first 
specify  basic  requirements  for  the  CPCI  as  a whole;  then  (b)  provide  a 
subsequent  separate  paragraph  devoted  to  each  type,  using  additional 
breakdowns  into  subparagraphs,  tables,  etc.,  as  necessary  for  the  given 
information.  In  some  systems,  adaptation  data  identifications  and  defini- 
tions have  been  provided  in  a separately-bound  appendix  to  the  development 
specification. 
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3.2  SECTION  2,  .VFPLICAHLE  DOCUMENTS 


Section  2 Applicable  documents.  The  content  of  this  section  shall  be  in  accordance  with 
paragraph  4.2  of  M1L-ST6-490, 


Paragraph  4.2  of  MIL-STD-490  sets  forth  requirements  for  this  section  which 
are  standard  for  all  UcD  specifications  and  fully  applicable  to  the  Part  I 
specification  for  a computer  program.  The  Instructions  Include  policies 
affecting  the  function  of  this  section,  the  handling  of  references  to  Govern- 
ment and  non-Govemment  documents,  and  examples  of  the  order  in  which 
documents  are  listed.  Points  of  general  interest  to  be  understood  and 
observed  include  those  summarized  briefly  below: 


a The  purpose  of  this  section  is  to  provide  an  organized  listing  of  all 
documents  referenced  in  other  sections  (Sections  3,  4,  and  5).  Docu- 
ments not  cited  elsewhere  in  the  body  of  the  specification  are  to  be 
excluded — l.e..  Section  2 is  a list  of  references,  not  a bibliography. 

• Each  document  listed  must  be  identified  specifically  and  accurately,  with 
respect  to  document  number,  title,  and  current  date  of  issue  and/or 
revision  status. 

• Each  document  listed  effectively  forms  a part  of  the  given  specification, 
but  only  to  the  extent  that  specific  requirements  set  forth  in  other 
sections  of  the  specification  are  stated  by  reference  to  the  given 
applicable  document.  The  proper  statement  of  any  requirement  by  reference 
is  normally  to  a specif ical ly-deslgnated  method  or  requirement  stared  in 
the  referenced  document. 

• In  the  event  of  conflict,  it  is  normal  Government  policy  that  any  require- 
ment stated  directly  in  the  given  specification  supersedes  requirements 
stated  by  reference  to  other  applicable  documents. 
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3.3  SECTION  3,  REQUIKEMEHTS 


Section  3 Requirements.  This  section  shall  contain  performance  and  design  requirements  for 
the  Cf*Cl . tt  shall  further  include  the  functional  requirements  for  the  CPCI  and  establish 
those  requirements  which  normally  will  be  verified  during  category  I,  or  equivalent,  test. 
This  section  shall  also  define  the  CPCI  and  specify  design  constraints  and  standards  neces- 
sary to  assure  compatibility  of  the  CPCI  with  other  computer  programs  and  equipments.  Per- 
formance and  design  requirements  to  be  included  herein  shall  be  allocated  from,  identical 
with,  or  in  recognition  of,  requirements  established  by  the  system/system  segment  specifica- 
tion. Requirements  included  in  the  system/ system  segment  specification,  which  are  directly 
related  to  requirements  specified  herein,  may  be  incorporated  by  reference.  Requirements 
shall  be  specified  to  the  level  of  detail  necessary  to  establish  limits  for  design.  Quanti- 
tative requirements  shall  be  within  the  three  principal  subparagraphs  included  herein.  The 
introductory  paragraph  shall  include  a general  description  of  the  CPCI  and  its  functions 
within  the  system/ equipment  to  which  it  applies. 


Section  3 constitutes  the  body  of  the  specification  as  a whole.  Its  purpose 
is  to  set  forth  all  requirements  necessary  to  govern  the  CPCI  design  and 
development  in  the  following  major  areas: 


• Characteristics  of  interfacing  systems,  equipment,  and  other  computer 
programs  which  affect  the  CPCI  design  and  operation  (paragraph  3.1). 

• System  functions  to  be  performed  by  the  CPCI,  including  detailed  input, 
processing,  and  output  requirements  pertaining  to  each  function  (para- 
graph 3.2.x). 

• Design  requirements  and  constraints  (paragraph  3.2.n). 

• Detailed  definitions  of  all  items  to  be  contained  in  the  CPCI's  fixed 
data  base  (paragraph  3.3). 


The  above  instructions  apply  primarily  to  Section  3 as  a whole.  Except  for 
the  last  sentence,  they  do  not  specify  information  to  be  supplied  in  a basic 
paragraph  under  the  section  number  and  title.  Since  general  descriptions 
of  the  CPCI  are  called  for  elsewhere  (e.g.,  in  paragraphs  1.2  and  3.2),  the 
basic  paragraph  is  frequently  omitted. 


3.4  PARAGRAPH  3.1,  COMPUTER  PROGRAM  DEFINITION 


3.1  Computer  program  Jef in  It  ion.  This  naragraph  shall,  in  subparagraphs  included  herein, 
specify  the  functional  rolationslii,)  of  the  CPCI  to  other  equipment/computer  programs  and 
identify  Government-furnished  computer  programs  incorporated  in  the  CPCI.  General  and/or 
descriptive  material  may  be  included  in  basic  paragraph  3.1. 

3.1.1  Interface  re(jui renients.  This  paragraph  shall  specify,  either  directly  or  by  refer- 
ence, requirements  imposed  on  the  design  of  the  CPCI  because  of  its  relationship  to  other 
equipment/coflouter  programs.  It  shall  also  include  detailed  interface  definition  resulting 
from  contractor  analysis  and  requirements  contained  in  the  system/system  segment  specifica- 
tion. General  and/or  descriptive  iMterial  may  be  included  in  basic  paragraph  3.1.1. 
Quantitative  requirements  shall  be  included  in  the  subparagraphs  included  herein. 

NOTE:  Interfaces  defined  in  this  section  shall  include,  at  a minimum,  all  relevant  char- 
acteristics of  the  computer,  sucli  as  memory  size,  word  size,  access  and  operation  times, 
interrupt  capabilities,  and  special  harA^are  capabi 1 i t ies.  The  computer  characteristics 
may  be  described  by  references  to  the  applicable  documentation  and  descriptions.  If  the 
compi ler/assembler  is  another,  or  part  of  another  Cl,  the  computer  program  language(s)  to  be 
employed  shall  be  specified  as  one  of  the  interfaces  in  sul'paragraph  3.1.1.?.  If  the 
compi  ler/assembler  is  a Government-furnished  component  to  be  incorporated  into  this  tl’CI, 
it  shall  be  referenced  in  subparagraph  3.?. 4.?.  If  the  compi ler/assemiiler  is  to  be  con- 
structed as  part  of  the  development  of  this  CPCI,  the  language  characteristics  shall  be 
defined  under  paragraph  3.2  Detailed  functional  requirenx>nts. 

3. 1.1.1  Interface  bloci,  diaijram.  The  relationship  of  the  CPCI  to  other  equipment/computer 
programs  with  wliicli  it  must  interface  shall  be  graphically  portrayed  in  this  paragraph. 

This  paragraph  shall  incorporate,  in  subparagraphs  as  appropriate,  a functional  block 
diagram  or  equivalent  representation  of  the  interface  requirements  of  the  CPCI.  The  graphic 
portrayal  of  the  CPCI  shall  be  accomplished  to  the  level  of  detail  necessary  to  identify  the 
functional  interfaces  between  the  CPCI  and  other  identified  equipment/computer  programs. 


3.4.1  Paragraph  Structure. 

This  paragraph  contains  one  more  level  of  breakdown  into  subparagraphs  than 
necessary.  An  earlier  version  of  the  instructions  included  another  subpara- 
graph which  was  moved,  at  the  time  MlL-STD-483  was  written,  to  its  present 
location  as  3.2.n.2.  Note  that  there  are  now  two  minor  errors  in  the  instruc- 
tions as  written:  (a)  the  requirement  to  identify  Government-furnished 
computer  programs  in  paragraph  3.1  is  now  redundant  with  later  instructions 
for'  paragraph  3.2.n.2;  and  (b)  in  the  fourth  sentence  of  the  NOTE  under 
instructions  for  paragraph  3.1.1,  "3. 2. 4. 2"  should  read  "3.2.n.2". 

Tlie  intent  for  paragraph  3.1  as  a whole  is  now  expressed  completely  in  the 
instructions  for  the  first  subparagraph,  3.1.1.  Hence,  it  is  reconmended 
that  the  specification  provide  only  the  number  and  title  for  3.1,  Computer 
Program  Definition,  followed  immediately  by  the  number  and  title  for  paragraph 

3.1.1. 


3.4.2  Interface  Requirements  - General 

Interfaces  to  be  identified  and  defined  in  this  paragraph  are  those  with 
systems  and/or  configuration  items  external  to  the  given  CPCI  (l.e.,  external 
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to  the  CPCI  only,  not  necessarily  to  the  system).  Interfaces  Internal  to  the 
CPCI  are  matters  of  computer  program  design,  which  will  be:  determined  later, 
controlled  by  the  responsible  developer  during  the  course  of  CPCI  development, 
and  documented  eventually  in  the  CPCI  Part  II  specification. 


The  primary  function  of  Interface  definitions,  here,  is  to  provide  the  devel- 
oper with  definitive  Information  about  all  relevant  characteristics  of 
equipment  and  other  computer  programs  with  which  the  giv 'n  CPCI  must  be 
designed  to  operate.  Considered  from  the  point  of  view  of  this  specification, 
responsibilites  are  summarized  as  follows: 


• The  Government,  not  the  developer,  is  responsible  for  ensuring  that  the 
external  items  will  prove  to  have  those  characteristics  when  the  CPCI  is 
eventually  put  into  operation.* 

• The  developer  is  responsible  for  designing  and  developing  the  CPCI  to  be 
fully  compatible  with  all  external  items  as  defined. 


The  style  of  specifying  interfaces  is  adapted  accordingly.  A statement  at  the 
outset  (in  paragraph  3.1.1)  that  the  developer  shall  design  the  CPCI  to  be 
compatible  with  all  Interfaces  defined  In  3.1.1  and  its  subparagraphs  is 
sufficient  to  be  directive  on  the  developer.  The  Interface  identifications 
and  definitions  are  then  provided  (in  the  subparagraphs)  in  descriptive  terms, 
representing  declarations  of  intent  on  the  part  of  the  Government. 


The  Instructions  above  for  paragraph  3.1.1  provide  for  specifying  interfaces 
"either  directly  or  by  reference".  The  use  of  references  for  specifying 
interfaces  should  observe  the  following  rules: 


• Reference  may  be  made  internally  to  other  portions  of  the  Part  1 specifi- 
cation itself.  Specific  practices  for  the  use  of  internal  reference. 


*With  respect  to  each  given  CPCI.,  this  principle  holds  even  if  the  same 
contractor  is  also  responsible  for  an  interfacing  item.  If  the  interfacing 
item  falls  to  meet  a specified  interface  requirement,  the  contractor’s 
responsibility  to  the  Government  for  that  failure  is  a separate  matter.  In 
principle,  the  given  CPCI  must  meet  the  interface  requirement  defined  in  its 
own  specification,  subject  only  to  the  resolution  of  problems  via  formal 
processing  of  engineering  change  proposals  (ECPs).  When  the  Part  I specifi- 
cations have  been  properly  prepared,  ECPs  required  to  resolve  interface 
problems  among  items  for  which  a given,  single  contractor  is  responsible 
should  normally  be  processed  as  compatibility  changes  (Code  C;  see  MIL-STD- 
480,  paragraph  4. 3. 2. 1.3). 
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relating  interface  ■essages  to  Inputa  and  outputs,  are  further  discussed 
In  3.8  below. 


e Reference  aay  be  aade  Co  other  docuaenCs  listed  In  Section  2 of  the  speci- 
fication. These  other  documents  may  Include:  specifications  or  other 
descriptions  of  Che  interfacing  Items;  Che  system  and/or  system  segment 
specif lcatlon(B) ; and  selected  other  references  which  should  also  normally 
be  cited  in  the  latter  (e.g.,  JCS  standards  for  isessage  formats). 

a References  to  Interface  control  drawings  (ICDs)  should  not  be  made.  They 
are  not  consistent  with  Air  Force  policy  and  are  not  advisable  (see: 
ref.  1,  pp.  1-11  and  1-31;  and  ref.  10,  pp.  78-80). 


NOTE:  It  is  reported  that  one  or  two  current  programs  are  finding  need  for 
extensive  uses  of  computer  program  ICDs  during  middle  and  late  stages  of  the 
development  period.  Infonsatlon  regarding  the  prospects  for  cost/schedule 
success  of  those  programs  is  not  available.  Together  with  the  Air  Force  stan- 
dards, this  guide  necessarily  assumes  that  each  PO  will  require  properly- 
prepared  Part  I specifications  as  a prerequisite  to  orderly  management  of 
contract  development.  When  that  does  not  occur,  however,  more  extensive  use 
of  ICDs  (and  various  other  compensatory  measures)  may  well  be  Indicated,  even 
as  a development  proceeds  Into  Its  later  stages.  As  indicated,  statements 
made  above  are  based  on  policy  set  forth  in  paragraphs  1-12  and  1-39  of 
AFSCM/AFLCM  375-7.  A few  key  considerations  relating  to  their  meaning,  intent, 
and  validity  are  summarized  briefly  as  follows: 

a ICDs  are  generated  by  an  Interface  control  working  group  (ICWG),  during  the 
full-scale  development  phase.  In  the  form  of  technical  agreenmnts  among 
Interfacing  contractors/agencies.  Traditionally,  the  prominent  concern 
during  that  phase  Is  with  equipment  interfaces  which  (a)  have  been  defined 
functionally  In  Part  I specifications  at  the  outset  of  the  phase  and  (b) 
must  be  defined  precisely  at  the  physical  level  as  the  development  proceeds. 
The  conventional  requirement  Is  that  those  physical  Interfaces  be  "final- 
ized" not  later  than  CDR.  Most  such  ICDs  are  later  referenced  in  the  Cl 
product  specifications,  together  with  other  detail  engineering  drawings  of 
Cl  design  and  construction.  Prior  to  PCA,  they  are  controlled  only  by  the 
ICUC,  not  by  the  PO's  configuration  control  board  (CCB). 

When  a program  does  not  have  a validation  phase  (which  happens  often),  many 
ICDs  may  be  generated  at  the  outset  of  full-scale  development  to  complete 
definitions  of  functional  Interfaces  required  in  the  system/system  segment 
and  Cl  development  specifications.  Theoretically,  those  should  be  com- 
pleted before  Cl  preliminary  design  efforts  are  Initiated.  Practically, 
it  is  recognized  that  some  may  be  delayed  until  approximately  the  time  of 
PDR  (see  paragraph  2-4,b,(l)  of  AFSCM/AFLCM  375-7).  When  completed,  they 
are  Incorporated  Into  the  system  and  Cl  development  specifications,  via 
ECP,  for  control  during  development  by  the  CCB. 
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• All  external  interfaces  of  a CPCI  are  functional.  Since  they  represent 
essential,  contractual  requlreoents  to  govern  computer  program  development, 
they  must  be  Incorporated  Into  the  CPCI  Part  I specifications.  The  CPCI 
Part  II  specification  does  not  contain  an  interface  requirements  paragraph, 
consistently  with  its  as-built  nature  and  absence  of  a contractual  require- 
ments role. 


e It  should  be  noted  that  AFSCM/AFLCM  375-7  (in  the  paragraphs  referenced  above) 
does  not  prohibit  the  preparation  and  use  of  computer  program  ICDs.  It 
requires  only  that,  when  interfaces  have  been  documented  initially  on  ICDs, 
their  definitions  be  incorporated  directly  into  the  Part  I specifications, 
rather  than  by  reference  to  the  ICDs.  That  requirement  is  fully  consistent 
with  the  policy  of  promoting  integrity  of  the  Part  I specification  as  an 
entity  in  itself,  avoiding  duplication  of  requirements  across  a multiplicity 
of  baseline  documents.  It  is  also  consistent  with  the  fact  that  the  SK>st 
prominent  interfaces  to  be  defined  are  message  inputs  and  outputs.  To  the 
degree  that  definitions  of  those  Inputs  and  outputs  are  not  known  and 
Incorporated  into  the  Part  I specification  at  the  time  it  is  placed  on 
contract,  there  is  a corresponding  absence  of  information  for  most  of  the 
specification's  required  basic  content. 


3.4.3  Interface  Identifications 

The  objective  for  paragraph  3. 1.1.1  is  to  identify  all  configuration  items 
and/or  external  systems  having  functional  Interfaces  with  the  given  CPCI.  A 
detailed  definition  for  each  interface  identified  here  is  then  to  be  provided 
in  the  next  paragraph  of  the  specif Icatlon,  3. 1.1.2  (see  3.5  below). 


Computer  prograaw  tend  to  Involve  external  relationships  which  are  often 
subject  to  question,  in  certain  areas,  regarding  whether  they  in  fact  consti- 
tute interfaces  to  be  identified  in  accordance  with  the  requirements  of  this 
paragraph  in  the  CPCI  Part  I specification.  The  following  comsients  address 
a few  of  those  "gray  areas". 


a.  The  phraae  "man-machine  Interface",  although  meaningful  in  another  con- 
text, does  not  imply  that  relationships  to  human  operators  are  to  be  included 
among  interfaces  identified  here.  In  general,  interface  control  is  confined 
to  relationships  among  computer  programs,  equipment,  and/or  facilities — l.e., 
the  inanimate  parts  of  a system  as  a whole  whose  characteristics  are  created 
by  system  designers/developors  end  documented  in  specifications.  For  com- 
puter programs: 

e Functional  characteristics  which  affect  the  CPCi's  compatibility  with 
human  operators  are  defined  as  integral  parts  of  the  requirements  speci- 
fied elsewhere  in  Section  3,  primarily  in  paragraph  3.2  (see  3.12  below 
for  a further  discussion  of  requirements  for  husMn  performance). 
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• In  all  caaas,  Cha  aan-aachina  ralatlonshipa  ara  aadlatad  through  oparator 
conaola  or  othar  aanual  input  and  diaplay  aquipaant.  Intarfacaa  of  tha 
CPCI  vith  thoaa  aquipaant  elaaanta  arc^  aignificant  intarfacaa  to  be 
identified  and  defined  in  tha  aubparagrapha  under  3.1. 


b.  In  a ayataa  prograa,  CPCIa  ara  involved  in  only  tha  firat  t%K>  of  tha 
four  major  claaaaa  of  intarfacaa  liatad  below;  and  both  of  thoae  are  alwaya 


applied  le: 

Sof tware/ Software 

Sof  tvere/Hardware 

V 

(N/A) 

Hardware / Hardware 

\ 

(N/A) 

Hardware /Facilities 

V 

c.  Although  tha  general  approach  to  opacifying  and  controlling  aoftvara 
interfaces  ia  derived  from  hardware  pracadenta,  certain  %rell-eatabliahed 
hardware  concepta  have  also  proved  to  be  sources  of  confusion  when  applied 
to  software.  Questions  arise  regarding:  ..(1)  the  distinction  bettreen 
"functional"  and  "physical"  interfaces;  (2)  the  related  practice  of  devel- 
oping interface  definitions  at  lower  levels  (physical)  during  the  course  of 
Cl  devalopaant;  together  with  (3)  the  practice  of  limiting  interface  iden- 
tifications to  interacting  items  which  share  a comtoa  point  or  region  of 
physical  contact.  Suggested  general  approaches  to  h^dling  those  questions 
are  summarised  in  the  following  comments: 

a All  interfaces  of  a CFCI  with  both  hardware  and  other  software  are 

regarded  as  functional.  They  should  be  defined,  ^ the  Part  ^ specifi- 
cation (again,  either  directly  or  by  reference;  see  3.4.2  above),  at  a 
level  of  detail  which  is  sufficient  for  all  purposes  of  (1)  guiding  or 
constraining  the  CPCI  developer  and  (2)  maintaining  Interface  control 
during  the  life  of  the  item. 

e Interfaces  to  be  defined  and  controlled  for  a CPCI  are  not  limited  to 
direct  interactions  with  other  items  in  either  space  or  time.  From  one 
point  of  view,  for  example,  an  applications  CPCI  operating  in  a given 
computer  Interfaces  "directly"  with  only  the  given  co^>uter  hardware  and 
other  software  operating  at  the  sasw  time  in  that  computer.  The  computer 
and  its  resident  operating  system  or  other  utility  software  do  represent 
prominent  Interfaces  to  be  identified  in  the  Part  I specification  and 
defined  (normally  by  reference  to  existing  documentation).  However,  the 
significant  operational  functions  of  the  CPCI  are  to  receive  and  process 
messages  input  from  remote  sources,  and  to  generate  messages  for  output 
to  remote  destinations.  Thus — for  the  specific  purpose  of  identifying 
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•llocacloM  of  rooponolblllcy  in  ch«  Port  I spocif lent ion— ch«  role  of 
the  CPCI  nay  be  regarded  aa  coaparable  to  that  of  a aail-order  queetion- 
and-answer  sarvicc,  in  that: 

—It  intarfacea  directly  with  the  aediating  hardware  and  aoftvare  (poet 
office)  with  reapect  to  certain  routine  aattera  of  foraat  (like 
addreaaea.  bulk,  ratea,  tiaing,  and  othar  rulea  for  aeaaage  tranapor- 
tation) ; but 

— Boat  iaportantly,  it  auat  be  capable  of  reaponding  to  aeaaage  content 
in  a aanner  which  ia  directly  coapatible  with  the  reaK>te  aourcea/deati- 
nationa  (cuatoaera),  involving  aattera  for  which  the  aediating  aervicca 
have  neither  the  reaponaibility  nor  the  capability  to  handle. 


Hence,  aa  auaawry  rulea:  CPCI  interfacea  are  identified  with  the  coaputer 
and  other  aoftware  operating  in  the  aaae  coaputer.  They  are  alao  identified 
with  all  other  Iteaa*,  both  hardware  and  other  aoftware,  which  affect  charac- 
teristics of  input  or  output  aeasagea  in  ways  over  which  the  coaputer  and 
its  support  aoftware  have  no  control.  The  latter  typically  Include  console 
or  other  input  and  display  capabilities,  recording  devices,  conaunlcat ions 
links,  and  other  applications  software  operating  in  different  coaputers. 


3.4.4  Eaaaple 

The  content  of  this  paragraph  aay  be  Halted  to  the  Interface  block  diagraa 
called  for  explicitly  in  Che  instructions.  One  exaaple  ia  illustrated  in 
Figure  6.  A specific  foraat  for  the  diagraa  is  not  specified.  However,  it 
should  be  noted  that  the  ''identification*'  is  accoaplished  basically  by 
providing  (a)  the  approved  noaenclature  of  each  interfacing  icea,  together 
with  (b)  a Cl  or  other  nuaber(s)  to  designate  the  itea  precisely.  If 
abbreviated  identifications  are  used  in  the  diagraa  to  conserve  space,  full 
identifications  (in  Che  fora  of  nuabers  and  approved  noaenclature)  aay  be 
provided  either  in  a separate  listing  keyed  to  the  diagraa  or  in  the  neict 
paragraph,  3. 1.1.2. 


*Interfaces  with  iteM  that  are  parts  of  another  systea  should  be  Identified 
as  interfaces  with  the  other  systea,  not  with  particular  configuration  itea 


□Software 
Interface 


Kartlware 

Interface 


OOtlier  Systea 
Interface 


Figure  ft  . Sanple  of  an  Interface  Block  Diagram  for  a Mlaalon  CPCI, 


NOTE:  Thla  example  la  chosen  to  Illustrate  principles  discussed  In  3.2.3,c 

above.  Indicating  that: 

e The  given  applications  (mission)  CPCI  has  direct  interfaces  with  the 
computer  in  which  it  operates,  and  with  the  resident  software  "operating 
system"  (O/S;  shown  as  the  Support  Computer  Program). 

# 

e All  Interactions  of  the  CPCI  with  elements  external  to  the  computer  are 
mediated  by  the  0/S  (as  indicated  by  the  surrounding  dashed  lines). 

e But  effective  interfaces  exist  between  the  given  mission  CPCI  and  other 
Items  or  systems  external  to  the  computer.  Those  must  be  Identified  and 
defined,  In  the  Part  I specification,  whenever  the  design  and  operation 
of  the  given  CPCI  will  affect,  or  be  affected  by,  functional  characteris- 
tics of  those  external  Items  or  systems. 
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3.5  PARAGRAPH  3. 1.1. 2,  DETAILED  INTERFACE  DEFINITION 


3. 1.1. 2 Detailed  Interface  definition.  This  paragiaph  shall  specify,  in  subparagraphs  as 
appropriate,  the  f"unctlona1  relationship  of  the  CPCl  to  interfating  equipment  and  computer 
programs.  This  Information  shall  be  given  in  quantitative  terms  with  tolerances  where  appli- 
cable to  the  level  of  detail  necessary  to  permit  design  of  the  CPCl.  functional  Interfaces 
shall  specify  the  Input/output  requirements  of  the  CPCl  in  terms  of  data  rate,  message 
format,  etc.  In  addition,  this  paragraph  shall  specify  design  requirements  imposed  upon 
other  equipment/computer  programs  as  a result  of  the  design  of  this  CPCl  (eg,  operator  con- 
sole equipment,  display  characters.  Junction  and  distribution  bones,  terminal  boards,  etc). 


3.5.1  General 


This  paragraph  ahould  be  organlted  Into  a sec  of  major  subparagraphs,  each 
corresponding  Co  one  of  the  ocher  icems/syscems  with  which  interfaces  were 
identified  for  this  CPCl  in  Che  preceding  paragraph  3. 1.1.1.  Suggested  general 
rules  for  specifying  the  detailed  interface  definitions  are  the  following: 


e The  computer,  its  standard  support  (non-functional)  software,  and  periph- 
eral input /output  equipment  should  normally  consist  of  items  which  already 
exist  prior  to  the  time  that  development  of  Che  given  system  CPCl  is  under- 
taken. Those  interface  characteristics  should  be  specified  in  Che  given 
CPCI's  Part  I specification  by  reference  to  the  applicable  documentation 
of  each  existing  item.  In  these  cases,  Che  major  burden  of  specifying 
interfaces,  here,  is  on  precise  identification  of  the  individual  items 
and  their  documentation,  with  attention  to  specific  type/model/version 
designations  where  applicable.* 

a If  a given  existing  item  is  being  modified  as  a part  of  this  system  program 
in  such  a way  as  Co  affect  its  interface  with  this  CPCl,  the  details  of  Chat 
aspect  of  the  interface  should  be  defined  directly  in  this  paragraph. 


e Interfaces  which  consist  of  swssages  input  to  the  given  CPCl  from  external 
sources,  or  output  to  external  destinations,  should  be  defined  directly  in 


*CQncurrenc  development  of  separate  CPCIs  expected  to  have  complex  operating 
Intaractions,  in  the  same  computer  (e.g.,  interacting  applications  functions; 
applications  vs.  operating  system  and/or  real-time  maintenance/diagnostics), 
is  a situation  to  be  avoided  if  possible.  If  such  elements  are  assigned  to 
separate  contractors,  with  concurrent  phasing  of  their  development  during  the 
program,  interfaces  can  easily  become  unmanageable.  If  assigned  to  one 
contractor,  they  should  normally  be  combined  into  a single  CPCl. 
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this  paragraph  or  by  reference  to  ocher  parts  of  this  CPCl  specification 
(see  3.8.2,b).  The  use  of  references  to  ocher  docuaents,  e.g. , the  system 
specification,  is  peraitted,  but  should  be  held  to  a ainiaua  (see  also 
3.4.2  above). 

e Interfaces  with  other  itens  being  developed  concurrently  should  be  defined 
at  Che  das  Che  specification  is  initially  approved,  as  well  as  they  are 
known;  and  the  nature  of  any  details  aissing  at  that  tiae  should  be 
described,  together  with  notations  Chat  chose  details  are  yet  to  be  added 
—e.g.,  in  the  fora  of  "To  Be  Deterained  (TBO)"  entries.  Such  TBDs  should 
be  replaced  by  the  required  detail  not  later  than  prellainary  design 
review  (PDR).  See  also  the  discussions  of  this  point  contained  in  AFSCM/ 
AFLCM  375-7,  paragraphs  2-4,b,(l)  and  2-5,c,(l). 


3.5.2  Examples 

As  Indicated  above  and  further  discussed  in  3.8.2,  message  interfaces  with 
external  iteas  and  systems  are  also  inputs  and  outputs  to  Che  CPCI  functions, 
and  Che  requirements  for  their  detailed  definitions  are  correspondingly 
similar.  For  examples  of  Che  proper  levels  of  InforaaClon,  see  Figures  11 
and  15  herein.  The  ninimua  information  to  be  specified  directly  in  this  para- 
graph should  consist  of:  (a)  Identification  of  Che  aeasage  (within  the  major 
subparagraph  for  that  external  icea/system) ; and  (b)  reference  to  Che  specific 
location  of  its  detailed  definition. 


The  following  Figures  7 and  8 illustrate  portions  of  the  interface  defini- 
tions chat  sdght  be  provided  for  Che  CPCi's  Interfaces  with  an  operator 
console.  For  an  existing  console  not  being  modified  under  Che  given  program, 
this  information  should  be  specified  by  reference  to  Che  console  documenta- 
tion. It  should  nomally  be  specified  directly  in  this  paragraph,  as  illus- 
trated, if  Che  console  is  being  developed  or  aodlfled  concurrently  with  respect 
to  those  aanual  entry  and  display  features. 
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3. 1 . 1 .2. 7.2. 1 Interceptor  t’ilot  Simulator  (U’S)  Console  Manual  [titry  llevice.  The  U’S  console 
manual  data  entry  device  consists  of  two  (2;  identicaT  input  l.eyl)oards,  each  with  compatihle 
assemblies  for  central  computer  interfaces.  The  keyboards  are  located  on  each  side  of  the  Data 
Display  Console.  Each  keyboard,  arranged  as  shown  in  Figure  J.8,  contains  four  (4)  modules; 
INTERCEPTOR  TRACK  NUllbER;  ACTION;  GENERAL  INPUT;  and  ACTIVATE. 

TRACK  NUMhER  is  entered  by  means  of  six  (G)  independent  sets  of  four  (4)  thumbwheels.  Adjacent 
to  each  set  of  thumbwheels  is  a selector  pushbutton  to  indicate  which  thumbwheel  set  is  to  be 
read  with  the  action.  The  GENERAL  INPUT  module  consists  of  three  (3)  sets  of  ten  (10)  push- 
buttons per  set.  They  are  used  to  enter  numerical  information  with  the  associated  action.  The 
ACTION  module  contains  a set  of  ten  (10)  pushbuttons  for  entry  of  the  type  of  action  desired. 


Fiijure  3.8.  IPS  Console  Keyboard  - iiodule  Layout. 


3. 1 . 1 .2. 7.2.2.  IPS  Console  Input  Message.  When  the  ACTIVATE  pushbutton  is  depressed,  the  con- 
tent of  the  four  (4)  thumbwheels  of  the  selected  TRACK  NUMDEK  module,  the  three  (3)  pushbuttons 
of  the  GENERAL  INPUT  module,  and  the  depressed  pushbutton  in  the  ACTION  module  are  assembled 
and  transferred  to  the  central  computer,  as  an  interrupt  message,  in  the  following  format; 


1 

TtlUMU 
WHEEL 
NO.  3 

THUMl! 

WHEEL 

NO.  4 

ACTION 

MODULE 

MODULE  ! 
NO.  1 1 

1 

G1 

MODULE 

NO.  2 

i 

■ng 

IBI 

1 

2-6 

7-12 

13-18 

14-24 

2,S-30 

31-31. 

37-42 

43-48 

3.). I. 2. 7. I Situation  Dtsplays.  Functional  relationships  of  the  Mission  CFCl  to  the  Situation 
Display  hardware  elements,  including  interactions  with  the  Operatinq  System  CPCI  whicii  affect 
this  interface,  are  outlined  in  Figure  3.10.  The  figure  depicts  the 'information  flow,  I/O  con- 
trol , and  Mission  CPCI  detailed  interface  requirements  associated  with  generating  and  presenting 
the  Situation  Display  information. 

3. 1.1. 2. 7. 1.1  Functional  Description.  The  Mission  CPCI  shall:  (a)  generate  Situation  Display 
Information,  utiliilng  stored  mission  data;  (b)  structure  display  messages;  and  (c)  determine 
the  routing  of  the  display  messages  through  the  hardware  elements,  in  accordance  with  the 
display  specification  data  specified  in  3. 1.1. 2. 7. 1.4  below.  The  Operating  System  CPCI  accom- 
plishes the  physical  transfer  of  the  Mission  CPCI  display  messages  to  the  Display  Drum  System 
as  specified  by  the  Mission  CPCI  in  the  I/O  Request  Message.  The  Drum  Controller  routes  the 
display  messages  to  their  assigned  Display  Drum  channels.  The  Display  Drum  transfers  all  dis- 
iMccjnitt  tg  refresh  the  CRT  Displays.  The  routing  of  individual  display  messages  to  the 


3. 1.1. 2. 7. 1,2  I/O  Request  Message.  The  Mission  CPCI  shall  generate  Request  Messages  for  Dis- 
plag  Drum  outputs,  each  consisting  of  three  (3)  words,  that  provide  instructions  to  the 
Operating  System  CPCI  for  tne  physical  transfer  of  display  messages  to  each  of  the  eleven  (II) 
Display  Drum  channels.  These  messages  shall  contain  the  information  defined  below; 


WORD  BIT  LOCATION 
1 1-18 

1 19-28 


CONTENT 

First  Word  Location  - Core  Memory  address  of  the  first  display 
word  to  be  transferred. 

The  number  of  display  words  to  be  transferred  to  Display  Drum 
Channel  Nufflber_l — — ~ 
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Figure  3.10.  Situation  Display  Interface  Diagram. 


3, 1.1. 2. 7. 1.3  Display  Messages.  Mission  CPCI -generated  display  messages,  consisting  of  one  or 
more  display  words  (one  word  is  required  for  each  character  to  be  displayed),  shall  provide  the 
coded  instructions  necessary  to  drive  the  CRT  Display  System  equipments.  A standard  display 
word  format  shall  be  used  which  shall  contain  the  following  information: 


BIT  LOCATION 


CONTENT 


1-3 

4-6 

7-16 

17-26 


Cl-Oisplay  Character  Set  First  Octal  Digit 
C2-0isp1ay  Character  Set  Second  Octal  Digit 
iX-POS  - Display  Coordinate  X Component 
iY-POS  - Display  Coordinate  Y Component 


Figure  3.  Interiats  Data  v csic'J  oext  page). 
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3. ). 1 .2. 7. 1,4  Display  Specification  Data.  The  Mission  CPCl  shall  generate  Situation  Display 
Messages  In  accordance  wuh  the  I’d! lowing  display  requirements: 

a.  Display  Character  Set.  Character  codes  for  the  Cl  and  C2  elements  of  the  standard 
display  word  shall  be  derived  utilizing  the  Display  Character  Set  matrix  illustrated  in  Figure 
3.11, 


FIRST  OCIAL  DIGIT 


Oi.  SID  H - O Y 
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a r - O _ U|© 

Figure  3.11.  Display  Character  Set 


b.  01  splay  Routing.  Category  values  for  the  A and  B elements  of  the  stahdard  display  shall 
be  derived  util iz^ng  Display  Routing  Category  Assignments  in  accordance  with  Table  XVI. 

Table  XVI.  Display  Routing  Category  Assignments. 


Category  Value 

Category  No. 

Bits  39-42 

Bits  44-48 

Category  Name 

(Switch  No. ) 

of  the 

of  the 

(Decimal ) 

Display  Message 
(Octal ) 

Display  Message 
(Octal ) 

Spare 

Interceptors 
Hostile  Class 
Friendly  Class  Tracks 
Tentative  Track  Reports 
Fonvardtold  Tracks 
Exercise  Data 
Exercise  Tracks 

^ fts&lflned  to  SD 


3 


04 

YY 

YY 

YY 

YY 

YY 

YY 

xy, 


Figura  8 (cont'd).  Sample  Oltplay  Intet'.ace  Data 
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3.6  PARAGRAPH  3.2,  DETAILED  FUNCTIONAL  REQUIREMENTS 


3.2  Detailed  functional  requirements.  This  paragraph  shall  specify,  in  subparagraphs 
defined  below,  the  functional  requirements  Of  the  CPCl.  Requirements  Shall  be  stated  In 
quantitative  terms,  with  tolerances  where  applicable.  General  and  descriptive  material  may 
be  included  in  basic  paragraph  3.2,  which  shall  incorporate,  either  directly  or  by  reference, 
a functional  block  diagram  or  equivalent  representation  of  the  CPCI.  The  graphic  portrayal 
shall  be  accomplished  to  the  level  of  detail  necessary  to  illustrate  the  functional  operation 
of  the  CPCl,  the  relationships  between  these  functions,  and  the  relationships  between  the 
functions  and  other  identified  system/ equipment  functions.  This  diagram  is  not  intended  to 
be  restrictive  on  computer  program  detail  design.  Requirements. for  separately  identified 
CPCl  functions  shall  be  described  in  subsequent  paragraphs  as  appropriate.  A subparagraph 
shall  be  included  for  each  operational  function,  plus  special  functions  such  as  sequencing 
control,  displays,  error  detection  and  recovery,  input  and  output  control,  real  time  diag- 
nostics, operational  data  recording,  etc.  The  descriptions  of  these  CPCl  functional  require- 
ments shall  include  the  relative  sequencing,  periodicies,  options,  and  other  important 
relationships  of  each  as  appropriate.  Paragraphs  3.2.x  and  subparagraphs  shall  be  repeated 
for  each  function  above. 


I 


1 


3.6.1  G»neral  | 

I 

I 

The  iaporCanc  objective  for  this  basic  paragraph,  3.2,  is  to  provide  an  I 

integrated  and  infomative  description  of  the  CPCl  in  terns  of  its  major  1 

operational  functions.  Its  purpose  is  to  describe  the  scope  of  functions  to  1 

be  perforaed  by  the  CPCl  as  a whole,  and  to  explain  the  sequencing  and 
interrelationships  among  the  major  functions  for  which  detailed  Input, 
processing,  and  output  requirements  are  set  forth  in  the  ensuing  structure 
of  subparagraphs.  « 

The  major  functions  described  here  should  typically  correspond  with,  or  be 

directly  traceable  to,  functions  described  in  the  system  specification  which 

were  allocated  to  this  CPCl.  Relationships  with  other  systems /equipment  to  be 

included  in  the  description,  in  accordance  with  the  above  Instructions,  should 

also  correspond  with  interfaces  identified  In  the  system/system  segment  sped-  - 

flcatlon. 


Note  the  instruction  to  Incorporate  a functional  block  diagram  or  equivalent 
representation  of  the  CPCl  functions  and  their  Interrelationships  in  a manner 
which  "is  not  Intended  to  be  restrictive  on  computer  program  detail  design". 
For  a complex  set  of  operational  requirements,  each  major  function  will 
normally  be  expanded  Into  its  subfunctions  and  then  Into  successively  lower- 
level  subfunctlons  as  may  be  necessary  to  arrive  at  a comprehensive  and 
definitive  set  of  performance  requirements  for  the  CPCl.  However,  the 
resulting  hierarchy  of  functions  does  not  dictate  a corresponding  structural 
organization  of  the  CPCl.  Computer  program  designers,  later,  will  normally 
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cr«at«  SOM  conpuCsr  program  componsnts  (CPCs)  or  modulss  to  perform  control 
or  support  functions  not  explicitly  specified,  or  to  perform  certain  process- 
ing operations  which  may  be  conmion  among  several  of  the  functlons/subfunc- 
tlons  defined  In  the  Part  I specification.  Thus,  a description  of  the  manner 
In  which  functions  delineated  In  this  paragraph  are  allocated  to  CPCs  is  a 
prominent  part  of  the  CPCI  design  to  be  examined  at  preliminary  design  review 
(PDR)  and  later  Incorporated  Into  the  CPCl's  Part  II  specification  (cf.  Instruc- 
tions In  paragraph  60.5.3.1  of  MIL-STD-483  for  this  Part  Il-level  description). 


3.6.2  Example 

Figure  9 Illustrates  a type  of  functional  block  diagram  which  has  proved  to 
be  very  useful  both  In  the  analysis  leading  to  a Part  I specification  and 
to  support  the  type  of  description  called  for  In  this  paragraph.  Som  of  the 
points  of  Information  depicted  in  the  diagram  are  explained  In  the  notes 
below. 

e Major  functions  allocated  to  the  mission  CPCI  are  identified  In  the 
central  blocks  (stairstep  arrangement)  of  the  diagram.  In  addition, 
the  diagram  as  a whole  shows  how  those  functions  relate  (a)  to  other 
software  and  hardware  elements  of  the  system,  (b)  to  external  systems, 
and  (c)  to  each  other. 

e Sollo  lines  with  arrows  are  used  in  this  diagram  to  indicate  Information 
flow  from  or  to  one  or  more  CPCI  functions  and  external  elements.  For 
example: 

— Incoming  radar  data  are  input  to  the  Air  Surveillance  Function,  via 
connunlcations  link, 

— Manual  Inputs  may  be  entered  Into  any  major  function  via  the  Keyboard 
Entry  Device. 

— Outputs  to  Interceptors,  via  communications,  are  generated  by  the 
Weapons  Control  Function. 

— Six  of  the  major  functions  generate  elements  of  displays  for  routing 
to  the  Display  Device. 

a Dashed  lines  with  arrows  indicate  that.  In  this  example,  each  major  func- 
tion generates  outputs  which  are  used  by  other  functions,  and  vice  versa. 


e For  purposes  of  this  paragraph,  the  accompanying  narrative  should 

describe  those  major  functions  and  their  Interrelationships,  Identifying 
the  nature  of  external  Inputs  and  required  outputs.  Obviously,  the  rels- 
tlonshlps  must  be  consistent  with  Interface,  Input,  and  output  identifica- 
tions provided  elsewhere,  notsbly  In  paragraphs  3.1.1,  3.2.X.1,  end 


3. 2.x. 3. 
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J.2  Detailed  Functional  Requirements.  Tho  Mission  Computer  Program  (MCP)  will  perform  auto- 
mated processing  required  at  each  Sector  Cont*^!  Center  (SCC)  of  tho  4XXL  Syst»*m  to  support  the 
operational  air  defense  functions  defined  for  each  SCC  in  the  System  Specification,  4XXL-3001A, 
Requirements  are  defined  herein  for  tho  MCP  to  perform  seven  (?)  major  functions  depicted  in 
Figure  3.2.1  and  described  below.  Of  those,  five  (b)  consist  of  the  primary  mission  functions 
of:  Air  Surveillance,  Target  Identification,  Weapons  direction,  Weaiwns  Control,  and  Sector 
Conmand.  Two  additional  functions  of  Simulation  and  Recording  are  defined  which  will  enable 
MCP  to  operate  in  the  system  exercising  mode,  in  conjunction  with  the  Ixercise  and  data  Reduc- 
tion CPCls,  without  disrupting  its  processing  of  live  environuwnt  data. 

As  Installed  at  each  CC,  the  MCP  will  be  adapted  to  operate  in  the  environment  peculiar  to  that 
SCC.  The  adaptation  will  consist  of:  (a)  fixed  data  pertaining  to  geographical  (wsitions,  air 
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3.7  PARAGRAPH  3.2.x,  FUNCTION  X 


3.2.x  Function  X The  basic  paragraph  for  each  function  shall  begin  with  descriptive  and 
introductory  material  which  defines  the  function  and  its  relationship  to  other  functions. 
Then,  the  following  three  subparagraphs  shall  specify  the  quantitative  regui renients  concern 
ing  the  function. 


Like  the  preceding  basic  paragraph  3.2,  this  basic  paragraph  for  each  major 
function  calls  for  an  informative  description  of  the  function  in  terms  of 
its  component  functions  (sub functions)  and  their  processing  Interrelationships. 
Together  with  the  preceding  description  of  the  CPCl  as  a whole,  the  purpose  of 
this  description  is  to  clarify  relationships  which  account  for,  but  may  be  less 
readily  apparent  In,  much  of  the  subsequent  detail  specified  for  lower-level 
functions. 


Figure  10  Illustrates  how  a functional  block  diagram  similar  to,  and  related 
to,  that  shown  previously  in  Figure  9 can  also  be  used  to  support  the  descrip- 
tion at  this  next  level. 


It  may  be  noted  that  paragraph  numbers  shown  in  Figure  10  (at  the  top  of  each 
function  block)  do  not  correspond  with  the  breakdown  into  Inputs/processing/ 
outputs  paragraphs  (paragraphs  3. 2.x. 1/2/3)  described  In  the  general  Instruc- 
tions. In  the  specification  from  which  this  example  is  drawn,  that  breakdown 
occurred  at  the  next-lower  level,  resulting  In  those  paragraphs  having  numbers 
of  the  form,  3.2.x.y.l/2/3.  For  example.  Inputs  and  outputs  for  the  Radar 
Processing  function  are  specified  in  paragraphs  3. 2. 2. 1.1  and  3.2.2. 1.3, 
respectively;  and  functions  at  still  lower  levels  are  Identified  in  further 
subparagraphs  and  sub-subparagraphs  under  the  processing  paragraph,  3.2.2. 1.2. 
Those  aspects  of  the  specification  structure  should  be  determined  by  the 
functional  complexity  of  the  given  CPCI. 
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3.2.2  Air  Surveillance  Function.  The  Air  Surveillance  function  encompasses  the  four  major 
functions  of  Radar  Input  (Processing,  Target  Tracking,  Track  Telling,  and  the  Surveillance 
S Display.  Figure  3. 2. 2.1  depicts  these  functions  and  the  general  nature  of  their  processing 

I Interactions  with  other  functions  both  Internal  and  external  to  Air  Surveillance.  Detailed 

j requirements  for  Inputs,  processing,  and  outputs  are  specified  In  a major  subparagraph  herein 

’ corresponding  to  each  of  those  functions,  as  Identified  In  Figure  3. 2. 2.1. 

Requirements  specified  for  the  Radar  Inputs  function  Include  requirements  for  coordinate 
conversions,  editing  of  radar  data  for  legality  of  formats  and  ranges  of  values,  correlation 
I of  radar  data  from  multiple  sensors,  and  the  generation  of  target  position  data  for  use  In 


Figure  3. 2. 2.1.  Air  Surveillance  Function;  First-Level  Functional  Flow. 


Figure  10.  Sample  Expansion  of  a CPCI  Major  Function, 

55 


3.8  PARAGRAPH  3.2.X.1,  INPUTS 


3.2. X.1  Inputs.  This  paragraph  shall  specify  either  directly  or  by  reference  to  another 
part  of  this  specification  the  source(s)  and  type(s)  of  input  information  associated  with  a 
function  of  the  CPCI.  This  shall  include  a description  of  the  information,  its  source(s) 
and,  in  quantitative  terms,  units  of  measure,  limits  and/or  ranges  of  units  of  measures, 
accuracy/precision  requirements,  and  frequency  of  input  inforration  arrival. 


(Recommended  Entry  for  CORE  Backup  Instructions) 


3.2.x.  1 Inputs.  Add  the  following  two  sentences:  "Inputs  received  from  other  functions, 
which  are  wholly  internal  to  this  CPCI,  shall  be  specified  at  a level  of  detail  which  is 
appropriate  to  clarify  those  functional  relationships.  Such  inputs  are  not  subject  to 
formal  qualification." 


3.8.1  General 

The  emphasis  in  this  paragraph  Is  on  providing  complete  Information  about 
Inputs  to  the  function.  Including  all  relevant  detail  which  will  be  needed 
as  a basis  for  CPCI  design  and  coding.  The  requirement  Is  to  identify  each 
input,  and  to  provide  for  each:  identification  of  its  source;  a name;  a 
precise  definition  of  the  item;  and  all  applicable  information  pertaining  to 
units  of  measure,  range  of  possible  values,  frequency/ timing,  and  accuracy. 
For  non-quantltatlve  inputs,  the  definition  must  contain  a listing  of  the 
possible  states  of  the  variable. 

Definitions  of  inputs  may  be  made  in  prose  and  tabular  form  as  best  fits  the 
nature  and  quantity  of  input  data  for  the  given  function.  Information  should 
be  grouped  into  subparagraphs  on  a meaningful  basis.  Paragraph/subparagraph 
numbers  and  letters,  together  with  input  names,  should  be  organized  in  such 
a way  that  each  individual  input  can  be  identified  without  ambiguity. 

The  process  of  gathering  and  organizing  detailed  information  about  inputs  is 
an  essential  part  of  analyses  performed  prior  to  and  during  preparation  of 
the  CPCI  development  specification.  This  paragraph  is  the  place  where  that 
information  is  recorded  and  controlled  for  the  life  of  the  CPCI.  The  infor- 
mation should  be  specified  in  meticulous  detail,  taking  into  account  certain 
qualifications  and  points  of  emphasis  noted  below. 


3.8.2  Notes 

a.  Role  of  Inputs  as  Requirements.  As  one  part  of  the  specification,  the 
role  of  information  specified  in  the  inputs  paragraphs  for  CPCI  functions 
tends  to  be  similar  to  that  of  interface  information,  in  that:  the  developer 
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is  constrained  to  design  the  CPCI  to  utilize  and  be  compatible  with  the 
Inputs  as  defined,  but  he  may  have  limited  or  no  responsibility  (depending  on 
the  source)  for  ensuring  that  the  inputs  will  prove  to  have  those  specified 
characteristics  when  the  system  Is  put  Into  operation.  This  consideration 
affects  (1)  the  manner  In  which  "requirements"  contained  In  the  Inputs  para- 
graph are  phrased  and  (2)  the  subsequent  handling  of  those  requirements  during 
the  test  program: 

• The  words  "shall"  and  "will"  are  both  used,  appropriately  to  the  actual 
Intent;  note  the  phrasing  of  sample  statements  illustrated  In  Figure  11 
below.  Usually,  the  appropriate  orientation  is  that:  Inputs  having  the 
specified  characteristics  will  be  provided  (to  the  given  function  devel- 
oper) ; and  the  developer  shall  design  the  CPCI  to  utilize  those  Inputs 
as  specified. 


a All  specified  Inputs  should  be  verified  during  the  qualification  process 
when  feasible  (see  Note  £ below).  However,  failures  of  certain  Inputs  to 
have  their  specified  characteristics  do  not  necessarily  imply  failure  of 
the  given  CPCI  to  fully  qualify. 


b.  Specification  by  Internal  Reference.  The  use  of  specification  by  refer- 
ence requires  the  use  of  coordinated  rules  affecting  other  parts  of  the 
specification,  considering  that  each  Input  will  be  Identified  elsewhere  as 
also  being  either:  an  Interface;  an  element  of  the  data  base;  or  the  output 
of  another  function.  One  useful  device  Is  to  organize  major  portions  of  the 
data  Into  separate  appendices,  providing  (as  examples): 

• One  common  appendix  containing  detailed  definitions  of  all  messages — l.e., 
messages  either  received  by  the  given  CPCI  from  an  external  source  or 
transmitted  from  the  CPCI  to  an  external  destination  (external  to  the  CPCI, 
not  necessarily  to  the  system).  Definitions  contained  In  the  common  appen- 
dix are  then  referenced  under  appropriate  subparagraphs  of  the  Interface 
paragraph  (3. 1.1. 2)  and  of  each  affected  paragraph  concerned  with  function 
inputs  (3.2.X.1)  and  outputs  (3. 2.x. 3). 

a Another  common  appendix  containing  detailed  definitions  of  data  base  items, 
which  Is  referenced  In  Its  entirety  under  the  data  base  paragraph  (3.3) 
and  appropriately  for  Individual  Items  In  the  Input  paragraphs  of  functions 
utilizing  the  data  base  as  a source. 

c.  Inputs  Prom  Other  Internal  Functions.  Special  problems  have  been  encoun- 
tered with  those  Inputs  and  outputs  which  are  peculiar  to  relations  among 
functions,  as  distinguished  from  Inputs/outputs  which  are  either  external  or 
associated  with  a fixed  data  base.  For  a variety  of  reasons.  It  Is  Inten- 
tionally not  required  that  the  CPCI  be  structured  into  components  (CPCs)  which 
correspond  one-to-one  with  functions  specified  at  the  Part  I level.  Thus, 
during  the  subsequent  process  of  computer  program  preliminary  design,  the 
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designers  are  free  to  allocate  the  functions  defined  in  the  Part  I specifi- 
cation to  some  different  number  of  CPCs.  As  a result,  many  inter-CPC 
relationships  will  exist  which  do  not  correspond  with  inter-function 
relationships  defined  in  the  Part  1;  and,  some  of  the  specified  input/output 
relations  peculiar  to  functions  may  be  handled  Internally  to  individual  CPCs. 


However,  those  implications  are  not  explicitly  recognized  in  the  MIL-STD-483 
instructions  for  this  paragraph  of  the  specification,  as  written.  Hence,  a 
set  of  CDRL  backup  instructions  similar  to  that  Illustrated  above  is  gener- 
ally applicable.  Recommended  rules  for  handling  that  class  of  inputs/outputs 
in  preparing  the  specification  are: 


• Define  the  characteristics  of  the  Item(s)  in  the  output  paragraph 
(3. 2.x. 3)  of  the  producing  function,  in  sufficient  detail  to  clarify 
the  functional  relationship  and  intent. 

• In  the  input  paragraph  (3.2.X.1)  of  the  receiving  function,  identify 
the  producing  function  as  the  source  and  specify  the  item  by  reference 
in  that  paragraph  (3. 2.x. 3). 

• Where  the  possibility  exists  that  specified  Input/output  relations 
between  internal  functions  may  be  altered  or  lost  in  the  process  of 
computer  program  design,  ensure  that  the  references  to  those  inputs 
and  outputs  are  properly  handled  in  preparing  the  Verification  Cross 
Reference  Index  for  Section  4,  Quality  Assurance  Provisions.  Generally, 
the  entry  "N/A"  is  appropriate  for  such  Inputs  and  outputs. 


3.8.3  Examples 


Illustrative  data  shown  in  Figure  11  are  adapted  from  a specification  which 
contained  complete  definitions  of  inputs  directly  in  the  input  paragraph. 

The  examples  illustrate  (a)  how  all  Inputs  to  the  function  may  be  identified, 
and  (b)  the  levels  at  which  complete  definitions  are  provided  for  a few  of 
the  identified  inputs. 


As  noted  above,  it  is  often  preferable  to  make  use  of  references  to  other 
parts  of  the  specification.  Efficient  organization  of  the  various  elements 
of  data  comprising  inputs,  outputs,  data  base,  and  message  Interfaces  is 
particularly  Important  when  the  total  volume  of  data  is  large.  From  the  point 
of  view  of  this  paragraph  (3.2.X.1),  the  detailed  definitions  of  all  inputs 
can  be  specified  by  reference.  However,  referencing  applies  only  to  detailed 
definitions.  Information  to  be  provided  directly  in  this  paragraph  should 
normally  consist,  at  a minimum,  of  a listing  (or  table)  of  all  inputs  to  the 
given  function,  including  for  each  input: 

• Name  of  the  input. 

• Source  of  the  input. 

• Reference  to  the  specific  location  of  its  detailed  definition. 


59 


Source  jnJ  Type  of  Ini'uts.  To  perform  the  I'ata  Iraiisfer  function,  the  MPlCt’  Shalt  he  designed  to 
accept  and  process  inputs  that  are  listed  in  Table  IV  and  defined  in  suhseouent  paragraphs. 

Table  IV.  Sunmarv-  of  Input  Sources  and  Types, 


TYPE  OF  INPUT 

SOURCE 

— 

UNITS 

LIMITS 

ACCURACY/ 

precision 

FRtOUlNCY 

Zulu  Time 

Manual 

Inputs 

hours  0-23 
Minutes  0-S9 
Seconds  0 59 

24  hours 

1 Second 

During  Startup 

TAOIL  R TO  Messages 

TACC 

j^Kefer  to  J.2.3. 

Maximum  of  29  messages 
per  second 

Equipment 

Assignments : 

Manual 

Inputs 

I/O  channel 
assignments 

/I/O  Channels 

0-3,  None 

N/A 

During  Startup 

Display  channel 
assignments 

Display 

Channels 

5-9,  iv’ne 

N/A 

During  Startup 

Teletype 

assignments 

Teletype 

Numbers 

0-4,  None 

N/A 

. 

During  Startup 

-Sindjtion  Test^' 

L — i_  j i ihromih 

" ^ 

J.2,3.1.2  TMTIL  K TO  Messages.  The  MUICP  shall  be  Capable  of  accepting  and  processing  TO  messages  input 
from  TACC  at  i^ates  up  to  2d  messages  per  second,  lach  message  consists  of  J words  having  the  core  format 
and  content  illustrated  in  figure  b below.  Ixplanations,  units,  acrnracy,  precision,  and/or  logical 
values  of  the  message  data  content  are  provided  in  Table  V. 


WORD 

BIT  POSITION 

BDOE9 

Dusiaa 

aaaa 

o 

o 

a 

Di 

1 

0 

TRACK  NUMBER 

ACTION 

IDEN- 

TITY 

r 

2 

3 

/ TRACK  X COORDINATE 

VALIDITY  CODE  (1) 

TRACK 

QUALITY 

P 

/ TRACK  Y COORDINATE 

VALIDITY  CODE  (2) 

B 

D 

B 

p 

Figure  6.  TADIL  R TO  Message  format  and  Content. 


Table  V.  TADIL  R TO  Data  Explanations  and  Characteristics. 


\MKUKM 

EXPIANATION 

UNITS.  LIMITS. 
ACCURACY.  PRECISION, 

OR  LOGICAL  VALUES 

wm 

___________________ 

A nimiber  assigned  to  each  TAOIL  R message  to  identify  the  type 
of  message. 

lOOOj 

(equal  to  lOg) 

TRACK  NUMBER 

The  reference  number  used  to  associate  information  and  direc- 
tions with  a particular  track. 

12  bits 

(equal  to  lOOOg) 

ACTION 

Indicates  either  la)  the  type  of  action  to  he  carried  out  by 
the  recipient  or  (b)  action  taken  by  the  originator. 

0 - Drop  track 

1 - Change  track  number 

2 - Forward- told  to  MTDS 
3-7  - Reserved 

TRACK 

COORDINATES 

The  position  of  the  track  in  X and  Y coordinates  relative  to 
the  coniion  coordinate  system  center  and  oriented  to  grid 

North  from  the  coordinate  center.  X and  Y coordinates  are 

LIMITS;  1511  3/4  data 
miles  for  each  coordi- 
nate; negative  values 
are  one's  cojilwr— * 

Figure  !1,  Sample  Identifications  ?nd  Definitions  of  Istps’Cs. 
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3.9 


PARAGRAPH  3. 2.x. 2,  PROCESSING 


3.2.X.?  Processing.  This  paragraph  shall  provide  a textual  and  mathematical  description  of 
each  of  the  processing  requirements  of  each  function.  Presentation  of  the  mathematical 
descriptions  under  each  function  shall  include; 

a.  Purpose  • This  area  shall  describe  the  exact  intent  of  the  mathematical  operation(s). 

This  involves  a definition  of  the  specific  input  and  output  parameters  and  the  processing 
required. 

b.  Approach  - This  area  shall  contain  a textual  description  of  each  mathematical  operation 
specified.  The  accompanying  narrative  shall  Identify  accuracies  required,  sequence  and 
timing  of  events,  and  relevant  restrictions  or  limitations.  Derived  equations  shall  be  shown 
with  appropriate  mathematical  and  control  symbols  adequately  defined. 


3.9.1  General 

The  purpose  of  information  in  this  paragraph  is  to  define  all  of  the  rules 
by  which  inputs  to  the  given  function  (specified  in  3.2.X.1)  are  transformed 
into  its  required  outputs  (specified  in  3.2.x. 3).  Although  not  amplified  in 
the  above  instructions,  all  processing  operations  must  be  specified,  whether 
or  not  they  are  normally  regarded  as  mathematical  computations.  For  example, 
they  may  Include  requirements  to: 

a Edit  inputs  for  legality,  and  to  generate  specified  output  messages  when 
Inputs  are  rejected  (see  3.12.2). 

e Perform  routine  retrieval,  sorting,  summarizing,  correlating,  and/or 
routing  of  data. 

a Perform  complex  modeling,  evaluation,  prediction,  or  any  other  data 
transformations  required  to  produce  the  necessary  outputs. 


3.9.2  Notes 


a.  Relations  to  Input/Output  Paragraphs.  In  the  course  of  defining  process- 
ing operations,  this  paragraph  necessarily  identifies  the  individual  Inputs 
and  outputs,  or  groups  of  those,  which  are  specified  in  the  preceding  and 
following  paragraphs,  respectively.  However,  the  specific  function  of  those 
other  paragraphs  is  to  provide  separately-organized  listings  of  all  inputs 
and  outputs  associated  with  the  given  f inaction,  together  with  the  detailed 
definition  of  each  item.  Thus,  this  paragraph  need  not  define  those  same 
detailed  characteristics  of  each  Item,  redundantly.  In  the  course  of  speci- 
fying the  processing  operations. 
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b.  Equations  vs.  Algorithms.  Many  processing  operations  are  properly  speci- 
fied by  means  of  mathematical  formulas  or  transformation  equations,  together 
with  definitions  of  their  symbols  and  terms.  The  term  "algorithm"  normally 
refers  to  a particular  procedure  and  sequence  of  operations  through  which  a 
given  set  of  computations  Is  performed.  An  equation,  for  example,  might  be 
solved  by  using  any  one  of  several  alternative  algorithms.  Considered  In 
that  light,  the  use  of  algorithms  to  specify  processing  operations  In  this 
paragraph  should  generally  be  avoided.  They  specify  design.  In  effect,  and 
have  proved  frequently  to  be  In  conflict  with  required  CPCI  performance.  It 
la  particularly  Important  that  the  content  of  this  paragraph  emphasize  what 
processing  Is  to  be  accomplished.  In  accordance  with  specified  performance 
criteria  (e.g. , of  speed,  timing,  volumes,  priorities,  end-result  accuracies), 
as  opposed  to  how  the  data  manipulations  are  to  be  carried  out. 


I 

i 


I 

> ■ 


H 


I 
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c.  Derivations.  Note  that  the  "derived  equations"  are  to  be  specified,  not 
their  derivations  as  such.  As  a general  rule,  derivations  (or  other  documen- 
tation of  system  engineering  analyses  leading  to  the  Part  I specification) 
are  not  proper  content  for  the  body  of  this  specification.  See  3.25  herein 
for  a further  discussion  of  derivations  and  alternate  methods. 


3.9.3  Examples 


Processing  operations  may  be  specified  In  the  form  of  narratives,  equations, 
tables,  graphic  aids,  or  combinations  of  those  as  appropriate  to  the  type  of 
function  being  described.  Figures  12  and  13  Illustrate  samples  for  only  two 
of  the  many  different  forms  of  presentation  and  varieties  of  functions  to  be 
encountered. 


Figure  12  Is  a sample  of  requirements  specified  for  a portion  of  the  calcula- 
tions Involved  In  scoring  air  Intercept  exercises.  In  a flight  simulation 
facility. 
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Figure  13  Is  a (modified)  sample  of  switch  action  processing  requirements  for 
an  air  defense  operational  computer  program.  The  two  tables  of  switch  action 
llsts,^own  at  the  bottom  of  this  figure  are  drawn  from  similar  tables  which 
were  organized.  In  the  actual  specification.  Into  a separate,  200-page 
volume. 
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3.2. 9. 2. 3. 4. 2 ttevation  checic.  The  target  shall  be  considered  within  the  vertical  gimbal  limits  if 
the  elevation  of  the  target  with  respect  to  the  manned  Interceptor  (a,)  is  less  than,  or  equal  to, 
the  Interceptor's  radar  gimbal  limits  in  elevation  (oeg).  The  angle  if  the  target  is  above 

the  Interceptor  and  a,g  • a,,j  if  the  target  is  below  the  Interceptor  (see  Figure  2a). 

The  angle  a.  shall  be  calculated  as  follows; 

. I "l  - 1 


Zj  • Altitude  of  the  Interceptor 
• Altitude  of  the  Target 

The  absolute  value  of  Zj  - Z^  is  used  since  the  Target  can  be  on  either  side  of  the  horizontal  plane 
of  the  Interceptor  (the  center  line  of  the  radar  volume). 

The  determination  of  the  value  used  for  o,g  shall  be  as  follows: 

a.  If  the  Interceptor  is  above  the  Target  (i.e.,  Zj  - Z^  is  positive).  Interceptor's 
lower  gimbal  limit  (ag^j)  will  be  used. 

b.  If  the  Interceptor  is  below  the  target  (i.e.,  Zj  - Zj  is  negative),  the  Interceptor's 
upper  gimbal  limit  (a^^)  will  be  used. 

If  the  Target  passes  the  range  and  elevation  checks,  the  Targefs  position  shall  be  translated  (to  the 
Xj,  Yj  axes)  and  rotated  (to  the  X2,  '<2  axes)  so  that  the  Interceptor's  position  and  heading  are  the 
reference  instead  of  the  AN/GYK-19  grid  center  and  true  north.  The  determination  of  the  Target's 
position  relative  to  the  manned  Interceptor  shall  be  computed  as  follows: 

X2  ■ Xj  cos  *2  - Vi  sin 
Vj  • X2  sin  «i2  Yi  *1 

where: 

*2  * Interceptor  heading  (true)  measured  in  the  X,Y  axis  system 


« The  Interceptor  to  Target  coordinates  computed  in  3. 2. 9. 2. 3. 4.1 


Vertical 

Upper 

Gimbal 


Interceptor 


AN/GYK-19 
grid  center 


Target  2 

(outside  gimbal  limits! 


Figure  2a.  Elevation  Check. 


^Target  1 

I ( inside  gimbal  limits) 

! 1^  - ^tI 


Vertical 

Lower 

Gimbal 

Limit 


X,Y  Plane 


3. 2. 9. 2. 3. 4, 3 Front  plane  check.  The  target  shall  be  considered  in  front  of  the  manned  Interceptor 
If  the  y^  position  is  greater  than  zero,  as  illustrated  by  Target  3 in  Figure  3 (Target  4 does  not 


Figure  12.  Sample  of  Processing  Requirements  for  an  Umpiring  Function. 
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3.2. 1.2.4  Switch  Action  lUta  |’rocessinq.  The  Mission  Computer  Program  (MCP)  shall  process 
Switch  Action  inputs  ^rom  the  Track  Management  Console  irt  accordance  with  the  criteria  defined 
for  each  Action  List  in  the  following  subparagraphs,  for  purposes  of  this  specification,  a 
Switch  Action  is  defined  as  a single  data  input  item,  such  as  Track  Number,  Power  Level,  etc.; 
a grouping  of  Switch  Actions  which  defines  a processing  requirement  for  the  MCP  shall  be  termed 
an  Action  List.  Prior  to  acceptance  of  Switch  Action  inputs  for  further  processing,  MCP  shall 
check  all  such  inputs  for  compliance  with  (a)  alphanumeric  format/content  specified  for  indivi- 
dual Switch  Action  inputs  in  3. 2. 1.1  and  (b)  restrictions  applicable  to  each  Action  List  for 
which  processing  is  specified  in  the  subparagraphs  herein. 

a.  Console  Input  Feedback  Display.  The  alphanumeric  characters  corresponding  to  each  Switch 
Action  shall  be  displayed  on  this  display  in  the  format  specified  in  3.2.1.3.27.  With  the 
exception  of  Track  Number,  all  individual  Switch  Actions  shall  be  displayed  in  the  order 
of  their  insertion.  Feedback  delay  for  each  Switch  Action  shall  not  exceed  0.2  seconds. 

(1)  Each  Action  List,  whether  legal  or  illegal  for  the  given  Unique  Track  Action 
Identifier,  shall  be  displayed  until  a new  Action  List  is  initiated. 

(2)  When  the  inserted  Action  List  is  legal  in  its  entirety,  and  MCP  initiates  the 
ordered  processing  on  a designated  Track,  the  Track  Number  shall  be  output  to 
complete  the  specified  content  of  this  display. 

b.  ILEG  and  Alarm  3.  Tlie  insertion  of  any  illegal  element  in  a track  Action  List,  or  the 
failure  to  insert  a required  element,  shall  (1)  cause  the  action  to  be  rejected  for 
further  processing  of  the  ordered  action,  (2)  activate  the  Illegal  Switch  Action  (ILEG) 
display,  and  (3)  activate  the  (audible)  Alarm  3.  The  ILEG  display  shall  continue  until 
a new  Action  List  is  initiated.  MCP  shall  clear  Alarm  3 after  3('l)  seconds. 


3.2. 1.2.4. 1 Assign/Reass i^n  Tracks.  This  Action  List  is  employed  by  the  Track  Manager  to 
assign  control  of  a specified  track  to  a specified  Weapons  Director  (WD). 


DATA  INPUT  ] 

RESTRICTIONS  ] 

PROCESSING 

I. 

Track  Number  (dddd) 

1.  The  Track  Number  must 

be 

1.  The  specified  track  shall 

one  assigned  to  an  existing 

be  assigned  to  the  specified 

2. 

WO  Designator  (WD1-W04) 

track. 

WD  for  processing  of  all  WD 
actions  specified  in 

3. 

Action  List  Identifier 

3. 2. 2. 2. 6. 

2.  Any  previous  assignment 
of  the  track  shall  be  de- 

assigned. 

3.  Assignment/ Reassignment 
displays  shall  be  forced  to 
the  affected  WD  consoles. 

3.2. 

. 1.2. 4. 2 Assign  SIF.  This 

Action  List  is  employed  by 

the  Track  Manager  to  assign  the 

Indicated  SIF  Mode  and  Code  to 

a specified  track. 

DATA  INPUT 

RESTRlCTIO.iS 

PROCESSING 

1. 

Track  Number  (dddd) 

1.  The  Track  Number  must 

be 

1.  The  specified  SIF  Mode 

one  assigned  to  an  existing 

and  SIF  Code  shall  be  assigned 

2. 

SIF  Code  Mode  (1.2, or  3) 

track. 

to  the  indicated  track. 

3. 

SIF  Code  (CHioo  - gggg) 

1 

2.  The  track  must  not  he 
told-in  track. 

a 

B 

Action  List  Identifier 

3.  The  track  must  not  be 
process  of  being  dropped. 

in 

Figure  13.  Sample  Specification  of  Switch  Action  Processing. 
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3.10  PARAGRAPH  3. 2.x. 3,  OUTPUTS 


3.2.x. 3 Outputs.  This  paragraph  shall  specify,  either  directly  or  by  reference  to  another 
part  of  this  specification,  the  destination(s)  and  type(s)  of  output  information  associated 
with  a function  of  the  CPCI  as  a result  of  the  processing  described  in  paragraph  3.2.2.  This 
shall  Include  a description  of  the  information;  its  destinaticn(s);  and,  in  quantitative 
terms,  units  of  measure,  accuracy/precision  requirements,  frequency  of  output  information, 
etc,  where  applicable. 


3.10.1  General 


As  viewed  by  the  intended  CPCI  user,  outputs  can  constitute  the  most  visible 
and  Important  portions  of  a Part  I specification.  Once  the  CPCI  is  developed, 
outputs  and  their  characteristics  tend  to  be  the  focal  criteria  for  evaluating 
its  performance,  both  during  formal  test  and  later  operations.  Hence,  the 
analysis  and  documentation  of  precise  requirements  for  outputs  should  be 
matters  of  Initial  and  continuing  emphasis  throughout  the  course  of  developing 
the  Part  I specification. 


Outputs  for  Che  given  function  may  be  specified  directly  in  this  paragraph  or 
by  reference  to  another  part  of  the  specification,  as  Indicated  in  the  instruc- 
tions. Unlike  Inputs  or  interfaces  with  existing  external  items,  outputs 
should  rarely  if  ever  be  specified  by  reference  to  other  applicable  documents. 
The  use  of  internal  references  for  tiie  detailed  output  definitions,  however, 
may  often  be  Justified  by  considerations  of  efficient  data  organization  and 
specification  maintenance,  as  for  inputs  (see  3.8  above).  Again,  the  minimum 
information  to  be  provided  directly  In  this  paragraph  for  each  function  should 
consist  of  a listing  of  the  function  outputs,  identifying  for  each: 

• Name  of  the  output. 

• Destination  of  the  output, 

• Reference  to  the  specific  location  of  its  detailed  definition. 


Detailed  and  precise  definitions  of  output  characteristics  are  generally 
mandatory  and  indispensable  for  outputs  external  to  the  CPCI.  There  is 
normally  less  need  to  provide  the  same  degree  of  precise  detail  in  defining 
outputs  to  other  functions  internal  to  the  CPCI,  for  reasons  discussed  earlier 
in  3.8.2.  However,  those  internal  outputs  should  also  be  identified  here,  in 
the  minimum  manner  described  above,  since  they  constitute  essential  links  in 
tracing  the  flow  of  information  across  functions.  For  that  purpose,  such  an 
output  can  often  be  defined  adequately  by  reference  to  the  portion  of  the 
processing  paragraph  (3. 2.x. 2)  which  describes  how  it  is  generated. 
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3.10.2  Examples 

Figure  14  provides  an  example  of  Che  minimum  listing  of  outputs  which 
should  appear  directly  in  this  paragraph  for  each  function.  In  this  partic- 
ular example,  it  happens  that  all  of  the  detailed  definitions  are  specified 
by  reference,  rather  than  in  the  listing  itself;  some  of  the  references  are 
Co  an  appendix  (for  message  formats)  and  some  to  subparagraphs  of  this  para- 
graph. 


Samples  of  the  detailed  definitions  for  two  of  the  outputs,  marked  as  "A" 
and  "B"  in  the  figure,  are  reproduced  in  Figures  15  and  i(,  , respectively. 


3.2.4. 3 Outputs.  In  performing  the  Track  Data  Transfer  function,  the  Interface  Computer  Program 
(ICP)  shall  produce  outputs  listed  in  Table  XIII  and  defined  in  paragraphs  referenced  therein. 


Table  XIII.  Destinations  and  Types  of  Outputs. 


TYPE  OF  OUTPUT 

DESTINATION 

UNITS  LIMITS  ACCURACY 

FREQUENCY 

TADIL  E messages 
M2 
M3 

NATS 

Refer  to  40.3.4.3.1 

Refer  to  40.3.4.3.2 

Max.  33  messages  per 
second 

TADIL  E messages 
M7 
M9 

TACC 

Refer  to  40.3.4.3.3 

Refer  to  40.3.4.3.4 

Every  20{i4)  seconds 

92-bit  MO  mes- 
sages; Position 
Velocity 

NATS 

Refer  to  40. 3.6. 3. 1 

Refer  to  40.3.6.3.2 

Max.  18  messages  per 
second 

10  recording 
request 

Simulation 

and 

Recording 

Real  time,  see  3.2.4, 3.1 

Non-real  time,  see  3.2.4. 3.2 

Max.  every  2 seconds 

Track  situation 
display 

Display 

console 

Refer  to  3. 2.4. 3. 3 ^ 

Refer  to  3.2,4.2.11 

Attention  situ- 
ation display 

Display 

console 

Refer  to  3. 2. 4. 3. 4 

Refer  to  3.2,4.2.11 

Console  alarms 

Display 

console 

Refer  to  3. 2. 4. 3. 5 

Refer  to  3. 2. 4. 2. 2 

Figure  14  . Sample  Table  of  Outputs  for  a Function. 
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40.3.4.3.1  TADIL  1 Messayes,  M2.  The  ICP  shall  output  M2  TADll  L messages  to  NATS  in  the  format  specified 
in  Figure  19  below.  Content  of  the  messages  shall  comply  with  definitions,  limits,  precision,  and  logical 
values  listed  in  Table  XXIV. 


M • Most  Significant  Bit;  L = Least  Significant  Bit. 

Figure  19.  TADR  f M2  Message  Format  and  Content. 


Table  XXIV.  TAOIL  I M2  Data  Ixplanations  and  Characteristics. 


DATA  TITLE 

EXPLANATION 

UNITS,  LIMITS,  ACCURACY, 
PRICISION,  OR  LOGICAL  VALUES 

TRACK  NUMBER 

The  reference  number  used  to 
associate  information  and 
directions  with  a particular 
track,. 

_J 

Four  decimal  digits, 

0000  - 4056 

LABEL 

1 

A number  assigned  to  each 

TADIL  E message  to  identify 
the  type  of  message. 

1000^;  0010  » M2 

0011  ’ M3 

0111  • M7 

1001  ■ M9 

HEIfiHT 

The  height  of  the  track  is 
the  contact  altitude  above 
mean  sea  level. 

LIMITS:  000  - 127,500  feet 

UNITS:  500  feet 

If  height  is  unknown, 
llllllllj,  is  transmitted 

VELOCITY 

Vclpcity  vector  of  the  track 
in  X and  Y components.  The 
most  significant  digit  of  each 
component  indicates  direction. 

LIMITS: 

tl27/12Fl  data  miles/sec 

UNITS: 

1/128  data  miles/sec 

Negative  values  are  reported 
as  one's  complement 

TRACK  QUALITY 

The  value  computed  by  the 
reporting  source  based  on  the 
freguency  of  its  data. 

0 - 7 (7  « highest  quality) 

TIME  TAC, 

Time  that  track  position  was 
observed  is  expressed  in  hours 
and  minutes,  Zulu  time. 

LIMITS:  0-23  hours 

0-59  minutes 

UNITS:  I minute 

Figure  15.  Sample  Definition  of  a Message  Output. 
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3.2,4. 3. 3 Track  Situation  Display.  The  Track  Situation  display  shall  be  presented  on-screen 
and  shall  appear  in  the  central  12"  by  12"  area  of  the  console  display  scope.  Its  position 
within  the  512  by  512  point  matrix  for  the  on-screen  area  shall  be  determined  by  the  location 
of  the  track  Identity  Symbol  representing  relative  geographic  location  of  the  track.  The 
display  shall  consist  of  a Track  Number,  Identity  Symbol,  Track  Age,  and  Track  History.  See 
Figure  26. 


TRACK  IDENTITY 


TRACK  AGE 


Figure  26. 


Relative  Geographic  Location  of  Tracks. 


The  displayed  elements  shall  comply  with  the  formats  and  definitions  provided  in  Table  XIV, 


Table  XIV.  Track  Display. 


PARAMETER 

CODE 

legal  valucs/explanation 

Track  Number 

ddd 

An  octal  number  representing  the  three  least  signifi- 
cant of  the  MTOS  track  number. 

Track  Identity 

r) 

Friendly  identity 

1 — 1 

Unknown  identity 

A 

Hostile  identity 

[ 

Special  identity  (not  expected  from  MTDS) 

Track  Age 

dd 

Time  elapsed,  in  minutes,  since  the  track  was  at  this 
position.  This  value  represents  the  difference  be- 
tween current  Zulu  time,  and  the  time  of  observation 
reported  for  the  track  in  the  most  recent  message 
received  from  the  MTDS  on  the  track. 

Track  History 

A vector  line.  Up  to  nine  vectors  can  be  displayed, 
connecting  the  ten  last-reported  positions  of  the 
track.  The  number  of  vectors  displayed  can  be  reduced 
by  the  Display  N Vectors  switch  action. 

Flgv ( e ' b. 


S i.mp  p Detlnt^Lon  ci  e Oisplav  Ovtpot . 
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3.11  PAKAGKAPH  3.2.n,  SPECIAL  REQUIREMENTS 


3.2.n*  Special  requirements.  This  paragraph  shall  specify,  in  appropriate  subparagraphs , 
requirements  which  affect  the  design  ot  the  CPCI  and  are  distinguishable  from  the  performance 
requirements  of  paragraph  3.  These  requirenents  result  from  general  considerations  of  CPCI 
usability.  These  may  include,  but  are  not  limited  to,  requirements  for: 

a.  The  use  of  programming  standards  to  assure  compatibility  among  computer  program  compo- 
nents (CPCs  - subprogram  or  groups  of  subprograms). 

b.  Program  organization,  such  as  oyerall  program  segmentation.  In  addition,  for  CPCls  which 
contain  or  process  classified  information,  special  attention  shall  be  giver,  to  the  require- 
ments for  protecting  classified  information. 

c.  Program  design  resulting  from  consideration  of  modifications  to  the  CPCI  during  operation 
(e.g.,  on-site  modification  requirements  and  the  permissible  amount  of  operational  degrada- 
tion allowed  during  installation  of  modification  may  be  specified). 

d.  Special  features,  to  facilitate  the  testing  of  the  CPCI.  Tor  example,  special  procedures 
for  the  design  of  CPC  Interfaces,  requirements  for  intermediate  printouts,  and  connientary  on 
the  program  listing  may  be  required. 

e.  Expandability  (growth  potential)  to  facilitate  modifications  and  additions  to  the  CPCI. 
n*  = The  next  sequential  number  following  the  number  of  the  last  function. 


(Recommended  Entry  for  CDRL  Backup  Instructions) 

3.2.n  Special  requirements.  Delete  instructions  for  this  basic  paragraph  in  MlL-STD-483  and 
repl ace  by  the  following: 

Design  requirements  for  the  CPCI  shall  be  specified  in  this  paragraph  (e.g.:  use  of  computer 
programning  language  or  other  standards;  requirements  pertaining  to  CPC  organization  or 
control;  limitations  in  utilization  of  computer  storage).  Design  requirements  specified 
herein  shall  be  the  minimum  necessary  to  meet  verified  needs  of  the  procuring  activity.  Tor 
CPCls  which  support  a system,  this  paragraph  shall  cite  paragraph  3.3.8  of  the  system  speci- 
fication and  incorporate  requirements  peculiar  to  this  CPCI  on  an  add  or  delete  basis. 

Design  requirements  shall  be  specified  to  the  maximum  extent  possible  by  reference  to  estab- 
lished military  specifications  and  standards. 


Changes  are  suggested  to  this  paragraph  largely  because  some  of  the  examples 
given  do  not  clearly  support  the  required  distinction  between  design  and 
performance,  e.g.,  protecting  classified  Information,  allowable  degradation. 
Intermediate  printouts.  "Commentary  on  program  listing"  is  a matter  to  be 
handled  via  CDRL  backup  instructions  to  the  Part  II  specification,  not  here. 


The  principal  function  of  this  paragraph  is  to  verify  or  modify  the  applica- 
bility to  this  CPCI  of  design  requirements/standards  specified  for  computer 
programs  in  paragraph  3.3.8  of  the  system  specification.  Unless  there  are 
good  reasons  in  a given  case  to  the  contrary,  this  paragraph  should  normally 
specify  the  same  requirements/standards,  either  directly  or  by  reference  to 
the  system  specification.  In  both  cases,  effort  should  be  made  to  minimize 
the  specified  design  requirements  and  constraints,  in  the  interests  of 
reducing  (a)  costs  and  (b)  the  ever-present  potential  for  conflict  with 
specified  perfonnance. 
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3.12  PARAGRAPH  3.2.n.l,  HUMAN  PERFORMANCE 


3. 2.0.1  Human  performance.  Human  performance/human  engineering  requirements  for  the  CPCl 
shall  be  specined  in  this  paragraph  (e.g. , minimum  times  for  human  decision  making,  maximum 
time  for  program  responses,  maximum  display  densities  of  information,  clarity  requirements 
for  displays,  etc.).  For  CPCls  which  directly  support  a system(s),  this  paragraph  shall 
cite  the  appropriate  paragraph(s)  of  the  system/system  segment  specification  which  establish 
the  human  performnce/human  engineering  requirements  for  all  system  equipment,  and  incorpo- 
rate requirements  peculiar  to  this  CPCI  on  an  add  and/or  delete  basis. 


(Recoimended  Entry  for  CORE  backup  Instructions) 

3.2.n.l  Hunan  performance.  Delete  instructions  for  this  paragraph  in  MIL-STD-483  and 
replace  by  the  following:  . 

For  CPCls  which  directly  support  a system,  this  paragraph  shall  cite  the  appropriate  para- 
graphs of  the  system  specification  which  establish  the  human  performance/human  engineering 
requirements  for  system  segments  and  equipment,  and  identify  the  degree  to  which  requirements 
peculiar  to  this  CPCI  are  incorporated  in  the  content  of  this  specification.  In  addition, 
this  paragraph  shall  provide  an  organized  list  of  the  human  engineering  criteria  employed  in 
determining  the  specific  requirements  documented  in  other  paragraphs  of  this  specification 
for  displays,  manual  inputs,  and  special  processing  to  support  operator  tasks  (e.g.,  the 
operator  shall  be  able  to  clear  all  display  alarms;  all  control  inputs  shall  have  a positive 
indication  that  the  input  has  been  accepted;  all  geographic  displays  shall  be  north-oriented, 
etc.).  Compliance  of  the  CPCI  as  a whole  with  these  criteria  shall  be  subject  to  human 
factors  test  and  evaluation  during  CPCI  qualification. 


3.12.1  General . 

This  paragraph  has  proved  to  be  a frequent  source  of  confusion  and  difficulty. 
Reasons  for  the  CDRL  Hackup  instructions  shown  above  are  outlined  oriefly  as 
follows : 


o The  general  intent  of  requirements  in  the  area  of  human  performance  is  to 
assure  that  the  "machine"  portions  of  a man/machine  system  are  designed  to 
be  compatible  with  natural  human  capabilities  and  limitations.  The  MIL- 
STL>-483  instructions  for  this  paragraph  are  based  on  equipment  practice, 
in  which  human  engineering  aspects  of  design  are  largely  incorporated,  by 
the  engineering  designers,  in  response  to  requirements  of  the  equipment  Cl 
development  (Part  I)  specification.  Requirements  are  often  stated  by  ref- 
erence to  human  engineering  standards  (MIL-STD-1472)  covering  such  con- 
siderations as  sizes  and  shapes  of  displays,  locations  of  controls, 
workspace  illumination,  etc. 


• In  a data  processing  system,  the  human  operator's  direct  interaction  is 
with  operator  consoles,  or  other  input /output  devices,  whose  man /machine 
compatibility  is  a joint  function  of  (a)  the  equipment  design  and  (b) 
functional  characteristics  determined  largely  by  the  computer  programs. 
Thus,  the  human  engineering  aspects  are  matters  of  computer  program/equip- 
ment interfaces,  as  well  as  of  the  separate  characteristics  of  those  two 
"machine''  elements  of  the  system.  From  the  point  of  view  of  the  computer 


program,  Che  characteristics  which  can  facilitate  or  hamper  efficient 
operator  performance  are  totally  functional — i.e.,  display  formats  and 
content,  timing,  responses  to  manual  inputs,  and  special  processing  capa- 
bilities to  support  operator  tasks. 


• All  of  those  characteristics,  however,  including  detailed  Interfaces  with 
Che  equipment  displays  and  manual  input  devices,  are  characteristics  Co  be 
analyzed,  verified,  and  defined  for  the  computer  program  directly  in  its 
Part  1 specification.  They  represent  portions  of  the  Parc  I specification 
which  are  particularly  significant  Co  its  evaluation,  approval,  and  eventual 
control  by  operational  personnel  of  the  using  command.  If  Che  system  engi- 
neering tasks  of  developing  the  Part  1 specification  are  properly  conducted, 
they  will  be  incorporated  throughout  the  input,  processing,  and  output 
requirements  (paragraphs  3.2.x. 1 through  3.2.x. 3)  specified  for  each  affected 
function  and  subfuncClon. 


Thus,  useful  functions  of  the  information  called  for  in  Che  recommended  backup 
instructions  are  to  provide  (a)  a summary  record  of  human  engineering  criteria 
employed  Co  derive  requirements  contained  in  the  Part  I specification  Itself, 
and  (b)  a direct  basis  for  human  factors  portions  of  Che  CPCl  test  program. 

The  content  of  this  paragraph  may  also  help  computer  program  designers  to 
understand  Che  reasons  for,  and  intent  of,  various  requirements  documented 
elsewhere  in  the  specification.  However,  it  should  not  normally  Impose  needs 
for  any  additional  computer  programming  or  human  engineering  design  work  during 
Che  CPCl  development. 


Statements  to  be  listed  in  this  paragraph  should  consist  of  criteria  which 
apply  generally  across  Che  CPCl's  various  functions.  Hence,  they  will  not 
cover  all  human  engineering  requirements  for  Che  CPCl,  since  many  of  those 
should  have  been  derived  through  considerations  specific  to  individual  func- 
tions. Guidelines  to  be  observed  Include  the  following: 


• The  statements  should  reflect,  in  fact,  systematic  attention  to  human  per- 
formance aspects  of  operations  Chat  are  required  in  Che  given  system. 


• They  should  be  concise  and  directed  towards  functions  performed  by  the 
CPCl,  as  distinct  from  equipment  or  the  human  operator — although  clearly 
related  to  chose  when  indicated.  They  should  not  include,  for  example, 
statements  such  as  "The  functions  and  locations  of  controls  sltall  ensure 
ease,  speed,  and  accuracy  of  operation...",  which  are  ambiguous  with 
respect  to  equipment  vs.  the  CPCl. 

• General  human  engineering  principles  should  be  included  if  they  can  be 
phrased  in  terms  that  are  (a)  clearly  related  to  the  given  CPCl  operation 
and  (b)  verifiable  during  CPCl  qualification.  Non-tesCable,  "motherhood" 
statements  should  be  avoided. 
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3.12.2  Exaaple 

Figure  17  lists  a few  statements  to  Illustrate  the  types  and  levels  of  con> 
tent  appropriate  for  this  paragraph. 


3.2.5. 1 Hunan  Performance.  The  Mission  Computer  Program  (MCP)  shall  be 
designed  to  comply  with  all  detailed  requirements  specified  in  3.2.1 
through  3.2.4  herein  for  manual  inputs,  display,  and  related  special 
processing  capabilities  required  for  efficient  and  error-free  performance 
by  the  system  console  operators.  Verification  of  the  MCP  design  and  per- 
formance for  compliance  with  those  requirements  shall  include  verifica- 
tion of  compliance  with  the  general  criteria  listed  below.  These  criteria, 
together  with  specific  requirements  incorporated  in  the  referenced  para- 
graphs for  individual  MCP  functions,  implement  human  performance/human 
engineering  requirements  allocated  to  the  Mission  Data  Processing  System 
Segment  in  paragraph  3. 7. 4. 6.1  of  the  system  specification. 


a.  All  manual  entries  from  the  operator  console  shall  be  error-checked 
and  verified  for  legality  before  being  accepted  by  the  functioning  com- 
puter program.  Positive  feedback  shall  be  provided  for  both  accepted 
and  rejected  manual  entries,  in  a manner  appropriate  to  criticality  of 
the  event  to  system  operations.  In  providing  that  feedback,  use  shall  be 
made  of  equipment  capabilities  provided  in  operator  console  design 
requirements  for:  digital,  situation,  and  input  displays,  including  in- 
put display  clearance;  computer-controlled  keyboard  interlock;  hardcopy 
output;  and  console  light  indicators. 


b.  The  lighting  of  Alarm  1 or  Alarm  2 at  the  operator  console  shall  be 
used  only  to  inform  the  operator  of  a situation  requiring  immediate 
action.  Displays  and/or  printouts  shall  be  provided  in  all  cases  when 
necessary  to  (1)  identify  the  reason  for  the  alarm  and  (2)  facilitate 
corrective  action. 


c.  Abbreviations  used  in  digital  displays,  including  digital  elements 
of  the  situation  display,  shall  comply  with  standards  set  forth  in  TAG 
Manual  302-15.  Non-standard  abbreviations  shall  be  used  only  when  (1) 
display  space  is  critical  and  (2)  their  meaning  is  obvious  to  the 
operator. 


n.  Each  symbol  used  to  provide  aircraft  identification/status  informa- 
tion in  the  situation  display  shall  have  only  one  meaning,  regardless  of 
track  identity,  console  operator  position,  or  mode  of  system  operation. 


Figure  17.  Sample  Content  for  the  Human  Performance  Paragraph. 
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3.13  PARAGRAPH  3.2.n.2,  GOVERNMENT-FURNISHED  PROPERTY  LIST 


3.2.n.2  Government- furnished  property  list.  This  paragraph  shall  list  the  Government- fur- 
nished computer  programs  which  the  CPCI  must  be  designed  to  incorporate.  The  list  shall 
identify  the  program  by  nomenclature;  specification  number;  model  number,  if  appropriate; 
and  associated  documentation. 


If  there  is  a requirement  for  the  contractor  to  physically  incorporate 
existing.  Government-furnished  computer  prograau  into  the  given  CPCI,  this 
paragraph  is  used  to  identify  those  items.  The  above  instructions  are  based 
directly  on  established  practice  in  specifying  equipment  CIs  (see  paragraph 
20.3.1.4  of  MIL-STD-490) , in  which  the  requirement  to  Incorporate  Government- 
furnished  components  tends  to  be  frequent.  However,  it  does  not  readily 
apply  to  CPCls  with  the  same  meaning  and  implications.  While  it  is  difficult 
to  rule  out  the  possibility  that  it  might  prove  useful  in  certain  special 
cases,  there  are  also  some  alternatives  and  potential  problems  which  should 
be  explored  and  resolved.  As  examples: 


e Existing  computer  programs  which  can  operate  in  the  same  computer,  and  are 
compatible  with  the  same  support  software,  are  usually  better  identified 
as  interfacing  Items  and  so  specified  In  accordance  with  requirements  for 
paragraph  3.1.1.  This  approach  should  be  considered  even  if  the  Government- 
furnished  Item  requires  modification,  and  by  the  same  contractor. 

• There  Is  a multiplicity  of  questions  that  can  be  raised  regarding  how,  or 
whether,  the  documentation  of  existing  items  can  be  reconciled  with  the 
new  Item's  specification,  at  both  development  and  product  levels.  In  the 
(unlikely)  event  that  the  existing  item  is  properly  specified  at  both 
levels  fully  in  accordance  with  MIL-STD-483,  much  of  that  documentation 
might  also  be  incorporated  into  the  new  CPCI  specification  (and  the  procuring 
activity  presumably  regards  the  CPCI  as  already  being  qualified  in  those 
respects).  In  the  event  that  performance  requirements  are  explicitly  speci- 
fied for  Che  first  time  in  the  new  CPCI's  development  specification, 
responsibilities  for  the  CPCI  qualification  can  easily  become  matters  of 
debate. 


• If  computer  programs  exist  which  perform  the  desired  functions,  but  require 
complete  redesign  and  coding  to  be  compatible  with  the  new  CPCI  and  its 
operating  environment,  their  "incorporation''  into  Che  new  CPCI  is  not 
properly  specified  in  this  paragraph.  Selected  algorithms,  if  fully  veri- 
fied, might  be  specified  as  design  requirements  (in  basic  paragraph  3.2.n, 
directly  or  by  reference).  Preferably,  their  documentation  might  be  made 
available  to  the  contractor,  separately  from  the  specification,  for  use  at 
his  own  discretion  (or  risk)  in  designing  the  new  item. 
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3.14  PARAGRAPH  3.3,  DATA  BASE 


3.3  Adaptation.  These  paragraphs  shall  specify,  in  descriptive  and  quantitative  terms,  the 
data  base  requirements  which  affect  the  design  of  the  CPCl.  In  addition,  where  applicable, 
these  paragraphs  shall  specify  the  methods  necessary  to  convert  these  parameters  into  a form 
suitable  for  use  by  the  computer  program.  These  requirements  are  divided  into  three  classes: 
general  environment,  system/ equipment  parameters,  and  system/equipment  capacities  shall 
be  presented  as  follows: 

3.3.1  General  environment.  This  paragraph  shall  contain  a description  of  environmental  data 
detailing  characteristics  anticipated  for  all  particular  installations.  Each  installation 
will  select  and  set  the  required  data  and  value  for  operational  use.  Examples  of  such  data 
are;  grid  limits,  radar  ranges  and  areas  of  coverage,  prescribed  safety  limits,  etc. 

3.3.2  System  parameters.  This  paragraph  shall  contain  a description  of  constants  required 
by  one  or  more  subprograms  that  may  change  from  time  to  time  incrementally  within  a speci- 
fied range  according  to  operational  needs.  Such  data  consists  of  allowable  trajectory 
deviations,  missile  performance  characteristics,  ranges  of  possible  values,  accuracy/preci- 
sion and  quantities,  etc. 


(Recommended  entry  for  CDRL  backup  instructions) 

3.3  Adaptation;  3.3.1  General  environment;  3.3.2  System  parameters.  Delete  instructions 
for  these  three  paragraphs  and  replace  by  the  following; 

3.3  Data  base.  Data  base  requirements  which  affect  the  design  of  the  CPCI  shall  be  defined 
fully  in  subparagraphs  herein,  including  precise  definitions  of  all  data  items,  together  with 
units  of  measure,  ranges  of  values,  and  accuracies/precision  where  applicable.  The  data  base 
encompasses  all  data  to  be  coded  and  inserted  into  the  system  prior  to  operation  of  the  CPCl. 
Data  definitions  contained  herein  may  be  organized  into  categories  which  are  meaningful  and 
appropriate  to  the  given  CPCl,  e.g.,  of  genera)  environment,  variable  parameters , or  others. 

Where  the  CPCl  is  intended  for  operation  at  multiple  sites,  or  in  various  mission  modes,  and 
is  to  be  adapted  for  those  uses  by  the  insertion  of  data  values  specific  to  each  site  or 
mission,  this  paragraph  shall  identify  and  define  all  such  adaptation  data  separately  for 
each  site  or  mission.  When  so  indicated,  data  definitions  may  be  provided  in  separate 
volumes  or  appendices. 


Purposes  of  the  change  reconmended  in  the  sample  CDRL  backup  entry  provided 

above  are: 

• To  alleviate  problems  which  have  resulted  from  a conflict  In  the  meaning 
of  "adaptation",  as  the  title  for  paragraph  3.3,  vs.  Its  established  Air 
Force  meaning  as  defined  In  the  backup  Instruction. 

• To  provide  greater  flexibility  in  tailoring  the  specification  of  data  base 
requirements  to  different  Individual  CPCls. 

• To  separate  the  specification  of  data  base  requirements  from  the  specifi- 
cation of  system  capacities  (see  3.15). 
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3.14.1  Notes 


II 


I 


The  statement  In  the  above  backup  instructions  that  the  data  base  "encompasses 
all  data  to  be  coded  and  Inserted  into  the  system  prior  to  operation  of  the 
CPCI"  is  somewhat  deceptive  in  its  simplicity.  In  practice,  situations  tend 
to  arise  which  indicate  that  no  single,  simple  rule  applies  in  the  same  way  to 
all  CPCIs.  The  comments  below  identify  a few  additional  rules,  together  with 
a few  sources  of  potential  confusion,  to  be  considered  in  determining  what  the 
data  base  should  consist  of,  for  purposes  of  the  Part  1 specification. 


a.  System  Requirements  vs.  CPCI  Design.  Here,  "data  base"  is  to  be  inter- 
preted strictly  in  the  layman's  language.  It  refers  to  files  or  tables  of 
data  whose  contents  are  of  interest  to  the  intended  operational  user,  which 
can  be  accessed  by  Che  operating  CPCI  for  purposes  of  retrieval  and  display, 
summarizing,  or  other  processing  uses  specified  for  the  Part  I specification 
functions. 


It  is  a source  of  frequent  and  slgniflccuit  confusion  chat  data  specified  here 
will  become  (when  coded)  only  one  portion  of  the  data  base  (software  language) 
to  be  later  specified  in  Che  CPCI  Part  II  specification.  The  latter  is  always 
more  extensive,  primarily  because  it  includes  all  transient  or  intermediate 
data  being  stored  temporarily  during  CPCI  operation.  The  computer  program 
designers  may  also  construct  and  use  some  tables  of  data  Co  perform  certain 
internal  CPCI  control  functions.  However,  Co  the  extent  Chat  those  considera- 
tions are  matters  of  computer  program  design  techniques,  they  are  not 
addressed  in  the  Part  I specification. 


b.  Data  Base  vs.  Other  Specified  Data.  Data  to  be  specified  here  as  part  of 
the  data  base  are  data  which  are  needed  as  Inputs  to  one  or  more  of  Che  func- 
tions specified  in  paragraphs  3.2.x,  but  which  are  not  specified  elsewhere  in 
the  Part  I specification  as  any  one  of  the  following: 

(1)  messages  input  from  sources  external  Co  the  CPCI; 

(2)  data  output  by  another  internal  CPCI  function  (specified  in  one  of 
the  output  paragraphs,  3.2.x. 3);  or 

(3)  data  for  which  values  are  specified  as  part  of  specifying  the 
processing  requirements,  directly  in  3. 2.x. 2 for  an  affected  function 
(e.g.,  mathematical  constants  used  in  equations). 

For  purposes  of  setting  forth  requirements  in  the  Part  I specification,  it  is 
often  optional  whether  certain  data  values  are  specified  in  the  last-mentioned 
category  (i.e.,  directly  in  a given  paragraph  3. 2.x. 2)  or  as  data  base.  That 
determination  should  be  made  by  the  Parc  I specification  writer  on  the  basis 
of  such  factors  as  convenience,  bulk  of  the  data  definitions,  considerations 
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of  specification  maintenance,  whether  the  data  apply  to  more  than  one  Part  I 
specification  function,  and — for  some  data  and  some  CPCIs— whether  it  is 
anticipated  that  some  of  the  values  will  later  be  systematically  inserted  or 
changed  for  desired  operation  of  the  CPCl  at  different  times  or  places. 


c.  Fixed  vs.  Variable  Values.  The  requirement  that  the  data  be  coded  and 
inserted  into  the  system  prior  to  operation  of  the  CPCI  is  subject  to  certain 
further  qualifications: 

(1)  It  may  not  apply  literally  to  the  entire  CPCl  in  all  cases.  As  in 
many  batch  processing  or  "data  base  management"  capabilities,  some 
system  CPCIs  may  include  functions  which  generate  and  maintain  the 
data  base,  as  well  as  other  functions  which  make  processing  uses  of 
the  current  data  base  at  the  time  of  their  operation.  The  reference 
in  the  instructions  is  primarily  to  the  latter  type  of  function. 

(2)  Even  when  actual  values  are  specified  in  the  Part  I specification,  to 
be  later  included  in  the  CPCl  code  at  the  time  of  Its  first  delivery, 
data  are  as  subject  to  change  as  any  other  elements  of  the  CPCl — and 
often  more  so.  When  it  is  desired  to  specify  an  initial  value,  but 
to  provide  for  future  modifiability,  the  data  may  be  specified  as 
"variable  parameters".  The  specific  purpose  of  specifying  a variable 
parameter  is  to  require  that  the  CPCl  be  designed  to  accommodate  later 
changes  of  the  Initial  value  in  specified  increments,  and  over  a speci- 
fied range,  without  affecting  the  computer  program  logic  or  design. 

(3)  For  some  classes  of  data,  Che  actual  values  may  not  be  known  in  advance 
of  developing  the  computer  program,  and  the  intent  is  to  provide  capa- 
bilities for  the  user  to  insert  the  values  after  the  CPCl  becomes 
operational.  Tables  of  security  data  to  be  employed  for  control  of 
data  base  access  by  multiple  users  would  be  one  example.  This  situa- 
tion might  apply  to  all  of  the  adaptation  data  (see  below)  in  some 
systems.  In  a mobile,  tactical  system,  for  example,  it  may  be  desired 
to  provide  capabilities  for  the  user  to  Insert  regularly  various 
elements  of  environmental  data  suitable  to  a given  location  or  mission. 

d.  Adaptation  Data.  Adaptation  data  are  defined  as  data  whose  values  are 
fixed  for  a given  site  or  mission  but  may  vary  for  different  sites  or  missions. 
This  concept  was  Initially  formalized  for  Air  Force  use  in  an  early  air  defense 
system,  which  was  to  be  lnstall'?d  for  operation  at  20  or  more  site  locations. 
The  requirement  was  for  a mission  CPCl  having  the  same  basic  configuration  at 
all  sites,  with  the  exception  that  it  be  "adapted"  to  each  site  at  the  time  of 
(or  prior  to)  installation  by  inserting  fixed  values  for  geographical 
coordinates,  airbase  designators,  and  numerous  other  environmental  data 
appropriate  to  the  location.  Requirements  pertaining  to  adaptation  data  in 
paragraph  80. 12.1. 2, e of  MIL-STD-483  for  the  version  description  document,  and 
in  paragraph  60.5.3.3.1  for  the  Part  II  specification,  refer  specifically  to 
the  class  of  data  described  here. 
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In  that  application,  the  concept  of  adaptation  data  was  the  same  as  the  cur- 
rent concept  of  CPCI  "types"  (see  3.1.2),  in  that  it  was  employed  basically 
as  a device  to  avoid  having  a multiplicity  of  CPCls  when  a single  CPCI  would 
suffice  with  only  minor  alterations  to  Its  configuration.  In  that  particular 
case,  adaptation  data  are  specified  in  two  ways  in  the  Part  I specification: 

(1)  For  the  basic  CPCI,  data  items  are  specified  as  variables — l.e., 
providing  data  definitions,  units  of  measure,  ranges  of  values,  and 
tolerances,  as  applicable  (such  aspects  as  frequencies  and  timing, 
which  are  significant  to  specify  for  inputs  from  external  sources, 
do  not  normally  apply).  This  set  of  requirements  will  later  affect 
the  computer  program  design,  which  should  be  accomplished  to  accommo- 
date the  specified  ranges  of  values  without  requiring  changes  in  the 
basic  computer  instructions. 

(2)  For  each  "type"  (location),  the  actual  value  is  provided  for  either 
all  or  a selected  subset  of  the  data  items — i.e.,  in  the  form  of  alpha- 
betic characters,  names  or  abbreviations,  and  decimal  numbers.  These 
requirements  later  affect  the  computer  program  code,  in  that  each 
"type"  delivered  with  a given  CPCI  version  contains  the  coded  actual 
values  for  that  site. 


e.  Configuration  Management  Considerations.  In  the  example  described  above, 
it  happ  .ed  that  the  variations  among  the  various  site  locations  were  confined 
to  adaptation  data.  However,  the  association  between  "types"  and  adaptation 
data  established  by  that  precedent  is  somewhat  incidental: 

• Differences  in  adaptation  data  are  likely  to  be  characteristic  of  types, 
but  differences  in  computer  instructions  should  not  necessarily  be  ruled 
out  if  they  are  minor  and  can  be  accomplished  in  a manageable  way  (see 
ref.  10,  para.  2.3). 

• As  indicated  in  c(3)  above,  provisions  for  the  CPCI  to  accommodate  adap- 
tation data  changes  may  be  Indicated  even  if  the  CPCI  is  not  classified 
into  more  than  one  type. 


Suggested  answers  to  a few  questions  which  arise  regarding  that  distinction 
are  summarized  briefly  as  follows: 

(1)  What  difference  does  it  make  in  specifying  adaptation  data  in  the 
Part  I specification  whether  CPCI  types  are  identified  or  not? 

(a)  If  types  are  identified,  as  in  the  air  defense  system  example, 
at  least  some  of  the  adaptation  data  will  be  specified  at  the 
level  of  fixed  but  different  values  for  different  sites,  in 
addition  to  being  specified  as  variables  for  the  basic  CPCI  [see 
d(2)  above]. 
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(b)  If  types  are  not  Identified,  all  adaptation  data  items  are  speci- 
fied as  variables.*  In  addition,  capabilities  for  the  user  to 
insert  the  actual  values  later,  either  prior  to  or  during  CPCI 
operation  (e.g.,  via  manual  Inputs),  are  also  specified.  — In 
this  case,  the  adaptation  data  values  do  not  affect  either  the 
CPCI  types  or  versions  (see  below). 

(2)  What  is  the  relationship  between  a CPCI  type  and  a version?  — Multi- 
ple types  are  indicated  when  the  intent  is  to  require — in  the  Part  I 
specification — that  one  CPCI  be  developed  for  initial  delivery  in  some 
number  of  different  configurations.  The  Intent  is  to  use  and  support 
that  given  number  of  separate  types,  concurrently,  for  the  life  of 
the  item.  Versions  of  the  CPCI  will  occur  as  changes  are  proposed, 
approved,  and  Implemented  to  the  CPCI's  basic  configuration  as  defined 
in  its  specification.  Each  new  version  or  interim  version  applies  to 
the  CPCI  as  a whole. 

(3)  How  do  configuration  control  procedures  apply  to  adaptation  data? 

— All  requirements  specified  in  the  Part  I specification  for  adapta- 
tion (or  any  other)  data  require  formal  Class  I change  processing  and 
approval  by  the  central  configuration  control  board  (CCB)  for  the 
given  CPCI.  Hence,  individual  data  items  should  be  specified  only  as 
variables  [as  described  in  Note  d(l)  above]  when  it  is  intended  that 
control  of  actual  values  be  exercised  by  Che  operational  user  or  a 
local  support  activity. 


3.14.2  Examples 


Samples  of  ways  in  which  elements  of  Che  data  base  were  specified  for  an  air 
defense  system  are  presented  in  Figues  18  and  19.  They  illustrate:  (Figure 
18)  tables  of  actual  values  for  data  to  be  coded  and  incorporated  into  the 
CPCI  for  use  in  Interceptor  guidance  calculations;  and  (Figure  19)  adaptation 
data  specified  in  Che  form  of  variables,  as  discussed  in  3.1A.l,d(l)  above. 

In  Che  latter  case,  actual  values  unique  to  each  site  were  contained  in  a 
number  of  separate  volumes  supplied  by  the  using  command  and  Incorporated 
into  Che  specification  by  reference. 


^Adaptation  data  may  consist  of  data  which  could  also  be  classified  as  environ- 
mental data,  security  data,  or  other.  The  point  is  that  the  "adaptation" 
label  is  a management  concept,  referring  to  any  class  of  data  which  is 
intended  to  be  changeable  for  purposes  of  adapting  the  CPCI  to  a given  set 
of  operating  circumstances.  The  specific  intent  may  be  either:  (a)  to 
provide  for  the  future  Insertion  of  actual  data  values,  under  local  controls, 
without  having  to  change  Che  specification  (in  which  case,  the  data  are 
specified  only  as  variables);  or  (b)  to  permit  different  actual  data  values 
to  be  specified  for  different  locations  or  use,  without  having  to  classify 
each  of  those  different  configurations  as  a separate  CPCI. 
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3. 3. 2. 2 Manned  Interceptor  Characteristics.  HCP  shall  utilize  the  data  values  recorded  in  tabular 
form  below  for  the  performance  predictions  and  guidance  calculations  unique  to  each  interceptor 
that  are  specified  for  Weapons  Control  processing  in  3. 2. 5. 4. 2 herein.  Definitions  of  symbols  and 
terms  specified  for  the  Weapons  Control  processing  requirements  apply  to  the  symbols  and  terms  used 
in  »h«tA  a-  ~ ' -"ntrir  l^cntifird  ^ 


Table  Vlll.  F9  Level  Flight  Speeds  (in  TMN). 


ALTITUDE  (feet) 

'^MIN 

Vmc 

'^MAXP 

1.000  

.33 

.43 

.83 

5,000  

.33 

.48 

.83 

10,000  

.38 

.53 

.83 

15,000  

.38 

.59 

1.03 

20,000  

.43 

.66 

1,03 

25,000  

.48 

.68 

1.18 

30,000  

.48 

.76 

1.38 

35,000  

.58 

.82 

1,48 

40,000  

.58 

.90 

1.43 

45,000  

.63 

1.00 

L --  - -- 

1.28 

Table  IX.  Stabilized  Level  Fuel  Consumption  (in  Pounds  per  Minute). 


ALTITUDE  (feet) 

CLEAN 

^MC 

TANKS 

CLEAN 

Vp2 

TANKS 

CLEAN 

Vmaxp 

tanks 

5,000 

98 

103 

215 

235 

1210 

1295 

15,000 

84 

96 

178 

195 

1280 

1130 

25,000 

79 

93 

140 

148 

918 

970 

35,000 

94 

100 

305 

552 

637 

671 

40,000 

99 

106 

370 

506 

531 

633 

45,000 

281 

380 

336 

459 

425 

572 

Table  X.  F9  Performance. 


SPEED  and  ALTITUDE  PARAMETERS 

CLEAN 

TANKS 

ALTITUDES: 

Optimum  Cruise  Altitude  (Zq) 

feet 

20,000 

15,000 

Optimum  Acceleration  Altitude  (Z^) 

feet 

20,000 

20,000 

Maximum  Maneuverable  Cruise  Altitude  (Z-jc) 

feet 

35,000 

35,000 

Coaltitude  Reference  (Zc) 

feet 

40,000 

40,000 

SPEEDS: 

Optimum  Cruise  Speeds  at  Zo  (Vo  at  Zq) 

IHN 

.81 

.76 

Maximum  Maneuverable  Cruise  Speed  at  Zy;  (V^y^X 

Za)  IMN 

1.20 

1.11 

Minimum  Snapup  Speeds  V^^) 

IMN 

1.18 

1.00 

PROFILES: 

Profile  1 (Vnyvxp  at  Cruise  Altitude) 

Prime  Cruise  Altitude  (Zpj) 

feet 

35,000 

35,000 

Vmaxp  at  Zpi 

IMN 

1.18 

1.00 

Profile  3 (Vq/Vmc  at  Cruise  Altitude) 

Prime  Cruise  Altitude  (Zq) 

feet 

25,000 

20,000 

Vo  at  Zo 

IMN 

.81 

.76 

Profile  4 (1.2Vx  at  Cruise  Altitude) 

Prime  Cruise  Altitude  (Zo) 

feet 

25,000 

20,000 

PERFORMANCE  TIMES:  (brake  release  to  Zo) 

Bus^fr  CXi»*> 

minutes 



Figure  18.  Sample  Data  Base  Specification  - Interceptor  Characteristics. 
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3.3.5  Adaptation  Data.  The  Mission  Computer  Program  (MCP)  shall  be  designed  as  a conmon,  adapt- 
able compuler  program that  will  operate  In  any  one  of  the  ten  Sector  Control  Centers  (SCCs)  of 
the  4XXL  System.  The  parameters  defined  In  Table  XXXII  herein  shall  apply  to  all  processing 
specified  for  MCP  In  3.2  above  wherein  adaptation  data  values  are  identified  as  required  Inputs 
to  the  processing  operations.  Actual  values  to  be  coded  and  Incorporated  into  MCP  prior  to 
Installation  at  each  SCC  are  those  contained  In  the  Identically-structured  tables  of  adaptation 
data  values  provided  for  the  ten  Individual  SCCs  In  Appendixes  XI  through  XX  of  this  specification. 


Table  XXXIl.  Sector  Environmental  Data  Parameters. 


ADAPTATION  ITEMS 

UNITS 

LIMITS 

ACCURACY/ 

PRECISION 

REMARKS 

SECTOR  COORD I NAT 
Iq  Confomal  Latitude 

Ag  Longitude 

Earth  Radius 

E CENTER  - C 

Radians 

Radians 

N. Miles 

EOGRAPHIC  COORD  INA- 
05l’gil57.0770 
01>gS314.1540 

Rg  - 5000 

"•E  CENTER  OF  THE  LO( 
4.84814  X 10'^ 
4.84814  X 10*® 
1/16 

EAL  CENTER 

Positive  North 

Positive  West 

At  Coord.  Center 

SECTOR  DISPLAY  CENTER  - LOCAJ 
Xp,  Yp  Components  | N. Miles 

L SECTOR'S  DISPLAY 
0<Xp.  Yp<1024 

CENTER  ON  STEREOCRAPHIC  PLANE 

1/4  j Sector  Center  Ref. 

RADAR  SITE  - PARJ 

Site  ID 

Conformal  Latitude 

Ap  Longitude 

R£  Earth  Radius 

Ap  Altitude 

Xp,  Yp  Components 

UIETERS  FOR 

LDOD 

Radians 

Radians 

N. Miles 

Feet 

N.  Miles 

EACH  RADAR  SITE  IN’ 

--  Unique  desigi 

0<lp<157.0770 

0<A^314.1540 

Rg  1 5000 

0<ApS  12000 
0<Xp,Yp<1024 

rERFACING  WITH  THE 

lator  for  each  radai 
4.84814  X 10*® 

c 

4.84814  X lO'® 
1/16 

100 

1/16 

.OCAL  SECTOR 

site  -- 

Positive  North 

Positive  West 

At  Radar  Site 

Above  S»a  Level 

Sector  Center  Ref. 

HEIGHT  FINDER  SH» 

Azimuth 
^A2  Limits 

UX)W  AREAS  - 

Degrees 

Degrees 

PARAMETERS  FOR  EA( 

osA^iseo 

AA^SIO 

:H  HF  AT  THE  RADAR 

1.0 

1.0 

;iTE 

Sector  North  Ref. 

COMPUTER  I/O  ASS 
Pj  Primary  Input 

Pp  Primary  Output 

S|  Secondary  Input 

Sg  Secondary  Output 

[GNMENTS  - Rj 

Chan  Mo. 

Chan  No. 

Chan  No. 

Chan  No. 

kDAR  COMMUNICATION 

00-64 

00-64 

00-64 

00-64 

CONNECTIONS  TO  I/O 

DNA 

DNA 

DNA 

DNA 

CHANNELS 

GATR  SITE  - PARAI 

Site  ID 

Xg,  Yg  Components 

Rp  Range  Radius 

lETERS  FOR  Ei 

LDDD 

N.  Miles 

N.  Miles 

ICH  GATR  SITE  INTEI 

— Unique  desigr 
OSXg,  Yg<1024 
O^Xp.  y"<1024 

IFACING  WITH  THE  LOC 

lator  for  each  GATR 

1/16 

1.0 

:AL  SECTOR 

site  -- 

Sector  Center  Ref. 

Figure  19.  Sample  Data  Base  Specification 


Adaptation  Data  (Variables). 
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3.15  I’ARAOIIAI’H  3.4,  SYSTEM  CAPACITIES 


Sys tern  capac i ti es . This  paragraph  shall  contain  a description  of  the  capacity 
requlrenwnts  for  the  computer  program.  Items  such  as  compatibility  for  total  simultaneous 
target  handling,  total  number  of  simultaneous  missile  trajectory  controls,  total  number  of 
simultaneous  displays  and  operator  station  requests,  track  capacity,  number  and  types  of 
Inputs  processed,  etc,  shall  be  described.  The  system  capacities  are  directly  related  to 
computer  storage  capacities,  Interfacing  subsystem  timing  rates,  and  Interfacing  equipment 
capabilities. 


(Reconricnded  entry  for  CDRL  backup  Instructions) 
3.3.3  System  capacities.  Delete  this  paragraph. 


I'lio  itjp.umbcring  of  this  paragraph  aa  paragrnph  3.4  corresponds  with  changes 
to  the  "Adaptation"  paragraph,  uoieu  in  cho  preceding  section  herein  (3,14), 
btised  on  a draft  version  of  MIL-STD--490A.  The  recommended  CDRL  backup  instruc- 
tion to  delete  the  paragraph  entirely  derives  from  the  failure  of  the  instruc- 
tions to  identify  how  or  whether  any  requirements  should  be  specified  here  which 
(a)  should  not  already  have  beor.  specified  In  preceding  paragraphs  of  the  speci- 
fication, or  (b)  are  really  the  proper  level  of  requirements  to  specify  in  the 
Part  I CPCI  specification.  Specifically;  

• The  statement  that  "system  capacities  are  directly  related  to  computer 
storage  capacities,  ..."  appears  to  be  included  for  explanatory  purposes. 
However,  it  suggests  an  orientation  more  towards  computer  program  design 
than  towards  requirements;  and  it  provides  no  clue  to  liow  those  capacities, 
rates,  and  capabilities  differ  from  requirements  to  be  specified  as  design 
requirements  (in  para.  3.2.n)  or  as  Interfaces  (in  par.a,  3.1.1). 


• "Number  and  typos  of  Inputs  processed"  is  directly  reilundant  with  the 
requirements  to  be  specified  in  the  various  inputs  paragraphs,  3.2.X.I. 


« The  reference  to  "compatibility  for  total"  simultaneous  targets,  missile 
trajectory  controls,  etc.  are  subject  to  various  Interpretations.  They 
might  refer  to  general  requirements  set  forth  in  the  system  specification. 
However,  the  responsibility  to  be  compatible  with  the  system  specification 
rests  primarily  with  the  developers  of  tlie  Part  I specification  Itself. 

The  repetition  of  system  requirements  here  is  merely  redundant,  at  best,  if 
those  have  been  properly  allocated,  analyzed,  and  converted  into  detailed 
requirements  for  the  CPCI  interfaces,  inputs,  outputs,  processing,  design 
constraints,  and  data  base  specified  in  preceding  paragraphs.  If  not,  the 
repetition  is  unlikely  to  alleviate  resulting  deficiencies  and/or  direct 
conflicts  among  Part  1 specification  requirements. 
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3.16  SECTION  4,  QUALITY  ASSURANCE  PROVISIONS 


Section  4 QuaKty  assurance  provisions.  Requirements  for  formal  verification  of  the  perfor- 
nance  of  the  CPCI  In  accordance  w^th  t^e  requirements  of  section  3 of  this  specification 
shall  be  specified  In  this  paragraph.  Formal  verification  of  performance  of  the  CPCI  shall 
determine  acceptance  of  the  CPCI.  This  paragraph  shall  specify  formal  verification  require- 
ments to  a level  of  detail  which: 

a.  Designates  verification  requirements  and  methods  in  section  4 for  perfoimance  and  design 
requirements  In  section  3.  The  methods  of  verification  to  be  specified  herein  may  include 
inspection  of  the  CPCI.  review  of  analytical  data,  demonstration  tests,  and  review  of  test 

data. 

b.  Specifies  requirements  for  verification  to  the  level  of  detail  necessary  to  clearly 
establish  the  scope  and  accuracy  of  the  test  method. 

c.  Permits  ready  Identification  of  each  verification  requirement  specified  in  section  4 with 
the  appropriate  performance/des iqn  requirement  paragraph  in  section  3. 

d.  Allocates  »eri  f i , at  t.'n  req  1 1 remeo  ( s to  the  subpa  raqraphs  included  herein. 

Nllll  Inis  section  sn*ll  n.n  >■.,><, hi,  r , eitnei  direstly  or  by  reference,  detail  test 
planning  docua^ntat  ion  and  operatin')  met  fn  t 'ons  Wmiui  > ement  s specified  herein  shall  be 
the  basis  for  preparation  and  validation  of  suih  Joiumrnts. 


3.16.1  General 

Note  chat  the  above  instructions  summarize  requirements  for  Section  4 as  a 
whole;  they  do  not  specify  content  to  he  provided  immediately  under  the  title 
of  Che  section.  In  a sinftle-volume  specification,  no  content  is  necessarily 
indicated.  When  Che  specification  is  prepared  as  a document  series,  statements 
should  be  provided  here  along  the  following  lines: 

• In  Volume  1 - "Quality  assurance  provisions  are  specified  in  this  section 

for  the  (title)  CPCI  as  a whole,  and  for  all  of  its  functions."  i 

e In  each  other  volume  - "Quality  assurance  provisions  for  the  (title) 
funcCion(s)  are  specified  in  Volume  1 of  this  specification." 


As  stated  in  Che  NIL-ikTD-483  Instructions,  the  real  emphasis  of  this  section 
is  on  specifying  requirements  for  formal  Cests/verlficatlons  which  will 
establish,  to  the  procuring  activity’s  satisfaction,  that  the  CPCI  meets 
performance  and  design  requirements  specified  In  Section  3.  Thus,  Section  4 
should  not  attempt  to  include  requirements  for  testing  to  be  carried  out  bv 
Che  developer  as  an  integral  part  of  the  CPCI  development  process.  The 
latter  ("informal  testing",  or  CPT6E)  la  Included  onlv  to  the  limited  extent 
outlined  in  3.19  below. 


t; 

1 1 
H 


82 


As  Indicated  in  Che  NOTE  contained  in  the  instructions,  planning  information 
as  such  (schedules,  numbers  and  sequencing  of  tests,  support  needs,  and 
procedures)  is  not  to  be  docuiuenCed  in  Section  4 of  the  development  specifi- 
cation. This  section  contains  the  contractually-appllcable  test  objectives/ 
criteria  to  govern  Che  formal  test  program  for  the  CPCl,  against  which  the 
adequacy  of  later-approved  test  plaiis  and  procedures  can  be  evaluated.  At  the 
same  time: 


• Planning  information  for  CPCl  qualification  should  normally  be  developed 
concurrently  with,  and  in  a mutually-supporting  relationship  Co,  develop- 
ment of  the  Section  4 requirements  (see  3.23).  But  it  shoud  be  documented 
separately  In  Che  form  of  a preliminary  version  of  the  formal  test  plan 
(DI-T-3703)  for  the  CPCl. 


• Planning  of  the  developer's  informal  test  program  should  be  accomplished 

and  described  in  the  computer  program  development  plan  (CPDP).  This  planning 
provides  the  basis  for  the  developer's  "requirements"  documented  in  paragraph 
4.1.2  of  the  specification  for  test  equipment,  facilities,  and/or  other 
Goventment  support  of  his  CPT&E,  including  (when  necessary)  time  for 
installation  and  checkout  of  a mission  CPCl  at  the  system  DT&E  site. 


3.16,2  Notes  on  Test  Terms  and  Concepts. 

a.  Verification  vs.  Test.  "Verification"  is  used  here  in  its  accepted 
English-language  meaning — i.e.,  referring  to  the  determination  that  something 
exists  or  is  true.  t\s  used  in  the  above  instructions  specifically,  it  is  a 
more  appropriate  term  than  "test",  since  it  implies  that  the  determination  can 
be  accomplished  by  various  methods.  Note  that  "test"  is  used  at  times  with 
that  same  broad  meaning  (equivalent  to  verification),  and  at  times  in  the  more 
limited  sense  of  one  particular  method — namely,  an  experimental  exercise 
yielding  performance  data — by  which  the  verification  is  accomplished. 


b.  Qualification  vs.  Acceptance  Testing.  "Qualification  testing"  refers  to 
the  process  of  verifying  (by  all  applicable  methods)  that  a newly-developed 
item  meets  the  requirements  of  its  development  specification.  Successful  com- 
pletion of  qualification  is  the  primary  basis  for  procuring  activity  acceptance 
(approval,  and  physical  transfer  of  possession)  of  the  item.  "Acceptance 
testing"  refers  to  routine  tests/verifications  conducted  on  production  units 
of  an  equipment  item  against  requirements  specified  in  Section  4 of  its  product 
(Part  II)  specification;  hence,  it  never  applies  to  a CPCl,  (This  distinction 
between  qualification  and  acceptance  testing  is  firmly  established  only  in  the 
Air  Force;  it  is  not  uniformly  observed  by  other  Government  agencies.) 
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3.17  PARAGRAPH  4.1,  INTRODUCTION 


4.1  Introduction.  This  paragraph  shall  establish  the  requirements  which  provide  the  basis 
for  development  of  a test  plan  and  test  procedures  for  the  subject  program.  All  test/verifi- 
cation requirements  shall  be  specified  within  the  subparagraphs  included  herein. 


General  or  introductory  statements  may  be  made  In  this  basic  paragraph  to 
explain  the  organization  of  requirements  or,  when  relevant,  to  identify  any 
significant  objectives  or  policies  which  apply  to  the  given  CPCI  or  system 
program.  Examples: 

• “Test  subcategories  and  methods  for  verifying  individual  performance/design 
requirements  specified  in  Section  3 are  summarized  in  the  Verification 
Cross  Reference  Index,  Table  (number) . Narrative  data  pertaining  to  each 
test  subcategory  are  specified  in  the  subparagraphs  below.  Amplified 
descriptions  of  test  methods  applicable  to  individual  Section  3 require- 
ments are  specified  in  4.2  and  subparagraphs  thereto." 

• "Verification  of  (title  or  abbreviation  of  the  CPCI)  compliance  with  basic 
performance  requirements  set  forth  in  Section  3 of  this  specification  shall 
be  accomplished  using  the  CPCI  configuration  adapted  to  the  (name  or  number) 
site  location.  Adaptation  of  the  CPCI  to  remaining  site  locations  will  be 
accomplished  by  the  Government,  subsequent  to  completing. system  DT&E." 

• "Modified  compiling  capabilities  specified  for  this  CPCI  in  3.2.x. 1 through 
3. 2.x. 3 shall  be  verified  through  formal  qualification  testing  specified  in 
4,1.4  below.  Other  functions  of  this  CPCI  shall  be  qualified  through  its 
successful  use  in  supporting  the  development  and  qualification  of  the 
(titles)  CPCIs." 
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3.18  PARAGRAPH  4.1.1,  CATEGORY  I TEST 


4,1.1  Category  1 test.  The  term  "category  1 test"  as  used  herein  is  defined  to  include  all 
testing  of  the  CPCl  other  than  that  accomplished  during  the  formal  category  II  (or  equiva- 
lent) system/ configuration  Item  test  programs.  (See  paragraph  4.1.5  below.)  Category  I 
testing  Is  subdivided  into  the  following  broad  types: 

a.  Computer  programning  test  and  evaluation  - Tests  conducted  prior  to  and  in  parallel  with 
preliminary  or  formal  qualification  tests.  These  tests  are  oriented  primarily  to  support 
the  design  and  development  process. 

b.  Preliminary  qual  ificatlon  tests  - Formal  tests  oriented  primarily  towards  verifying 
portions  of  the  CPCI  prior  to  Integrated  testing/ formal  qualification  tests  of  the  complete 
CPCI  Uee  paragraph  4.1.3  below).  These  tests  will  r)|.  Lj.  > in  .onducted  at  the  contrac- 
tor's design  and  development  facilities. 

c.  Formal  qualification  tests  - Formal  tests  oriented  primarily  towards  testing  of  the 
Integrated  CPCI,  normally  using  operationally  configured  equipment  at  the  category  II  site 
prior  to  the  beginning  of  category  II  testing.  This  testing  will  emphasize  those  aspects  of 
the  CPCI  performance  which  were  not  verified  by  preliminary  tests.  The  testing  requirements 
which  cannot  be  verified  during  category  I test  shall  be  specified  in  paragraph  4.1.5. 

NOTE:  Requirements  for  verification  included  in  the  system/system  segment  specification, 
which  are  directly  related  to  requirements  specified  herein,  may  be  incorporated  herein  by 
reference  to  avoid  redundant  establishment  of  the  requirements. 


The  "category  test"  terms  contained  In  the  above  Instructions  have  been  out- 
dated as  a result  of  revisions  which  appeared  first  in  the  12  May  1972  issue 
of  APR  80-14.  In  the  specification,  they  should  be  replaced  (via  authority 
provided  in  CDRL  backup  Instructions,  pending  the  Issuance  of  MIL-STD-490A) 
by  the  current  terms  in  accordance  with  the  following  simple  conversion: 

Category  I Test  — ► CPCI  Development  Test  & Evaluation  (CPCI  DT&E) 

Category  II  Test  — ► System  Development  Test  & Evaluation  (System  DT&E) 

Other  terms  used  to  distinguish  the  three  types  (subcategories)  of  Category  I 
test — namely,  CPT&E,  PQT,  and  FQT — and  their  definitions  as  provided  above, 
are  unaffected  by  those  changes. 


Again,  note  that  the  instructions  provide  information  only,  defining  the  types 
of  testing  under  CPCI  DT&E  to  be  covered  in  remaining  subparagraphs  of  4.1. 
They  do  not  specify  the  content  to  be  provided  in  this  basic  paragraph. 
Depending  on  applicability^  to  the  given  CPCI,  statements  may  be  provided  here 
to  clarify  the  test  policy  with  respect  to  defined  subcategories  of  tests 
along  lines  suggested  by  the  following  examples: 

• "Qualification  of  this  CPCI  shall  be  accomplished  during  CPCI  DT&E  to  the 
maximum  extent  possible,  as  a result  of  PQTs  and  FQTs  conducted  by  the 
developer  and  witnessed/verified  by  the  procuring  activity." 
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"Qualification  of  selected  requirements  during  CPT4E  shall  be  limited  to 
tests  conducted  under  controlled  conditions,  using  documented  procedures. 
Results  of  such  tests  shall  also  be  documented,  and  the  developer  shall 
make  such  documents  available  as  evidence  of  verification  to  representatives 
of  the  procuring  activity  during  functional  configuration  audit  (7CA)  of 
the  CPCI." 

"Qualification  of  requirements  during  system  DT&E  shall  be  limited  to 
requirements  which  cannot  be  demonstrated  satisfactorily  during  CPCI 
DT&E  due  to  the  absence  of  the  full  equipment  configuration  and  operating 
intersystem  communications." 


3.19  PARAGRAPH  A. 1.2,  COMPUTER  PROGRAMMING  TEST  AND  EVALUATION 


4,1.2  Computer  progranwing  test  and  evaluation.  This  paragraph  shall  contain  the  following; 

a.  Prograinnfng  test  and  evaluation  which  satisfy  one  or  both  of  the  criteria  listed  below 
shall  be  included  herein.  (Routine  tests  accomplished  in  support  of  design  and  development, 
which  do  not  satisfy  one  or  both  of  these  criteria,  shall  not  be  specified  herein.) 

(1)  They  are  intended  to  be  the  only  source  of  data  to  qualify  specific  requirements 
in  section  3. 

(2)  They  must  be  accomplished  as  part  of  an  integrated  test  program  involving  other 
systems/equipment/computer  programs  (eg,  verification  of  requirements  in  paragraph  3.1.1.) 


"CPT&E"  is  Che  label  applied  Co  Che  developer's  InCemal  (l.e,  informal) 
CesClng  accomplished  as  a pare  of  his  CPCI  developmenC  efforc,  in  concrasC  Co 
formal  cesCing  for  purposes  of  quailf IcaClon.  IC  is  assumed*  chac  a developer 
has  InCemal  plans  and  procedures  for  conducCing  CPT&E,  ranging  from  code 
checking  and  debugging  Chrough  CPC  and  performance  CesCing  aC  successively 
higher  levels,  and  ChaC  chose  are  adequaCe  Co  meeC  Che  Cechnical  needs  of  com- 
puCer  program  developmenC.  The  conduce  of  Che  inCernal  CesC  program  as  a 
whole,  however,  is  largely  irrelevanC  Co  Che  purposes  of  chls  section  (Quality 
Assurance  Provisions)  of  Che  developmenC  specif IcaClon.  As  stated  in  Che 
instructions,  material  should  not  be  specified  here  about  CPT&E  as  such  (or 
elsewhere  in  Section  A)  except  where  Government  recognition  is  specifically 
needed  for  Che  two  reasons  stated.  Those  two  types  of  "requirements",  and  Che 
ways  in  which  they  should  be  specified,  are  discussed  separately  in  Che  two 
subparagraphs  below. 


3.19.1  Test  Requirements. 

A "test  requirement",  in  Section  A,  is  generally  a statement  that  a given 
performance  or  design  requirement  set  forth  for  Che  CPCI  in  Section  3 is  to 
be  verified  during  a given  subcategory  (type)  of  DT&E,  by  an  identified 
method  (see  3.21  below).  Successful  verification  constitutes  qualification 
of  the  CPCI  with  respect  Co  the  given  requirement. 


Although  CPT&E  is  not  basically  a part  of  the  formal  test  program,  it  is 


*Or  judged  independently  of  this  specification.  For  example,  descriptions  of 
planning  for  Internal  CesCing  are  required  as  a portion  of  information  to  be 
supplied  by  a developer  in  his  computer  program  development  plan  (CPDP). 
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recognized  as  one  possible  source  of  data  by  which  the  formal  qualification 
can  be  accomplished  for  some  Section  3 requirements.  For  CPCls,  the  Judicious 
use  of  CPT&E  for  that  purpose  should  be  considered  seriously  from  the  point  of 
view  of  reducing  the  burden  on  formal  tests /demonstrations,  in  which  the  number 
of  requirements  that  can  be  demonstrated,  in  depth,  is  typically  limited. 
Requirements  of  a detailed  nature  which  are  relatively  independent  of  inter- 
facing operations,  or  certain  requirements  whose  verification  entails  lengthy 
compilation  and/or  analysis  of  test  data,  are  likely  candidates. 


When  CPT&E  is  identified  as  the  source  of  qualification,  however,  those 
selected  tests  must  be  conducted  and  documented  by  the  developer  in  a manner 
which  is  more  formal  than  may  be  typical  of  his  internal  test  program  as  a 
whole:  The  tests  must  be  conducted  strictly  in  accordance  with  documented  test 
procedures,  including  listings  of  input  data;  and  the  test  results  must  be 
fully  recorded,  including  hardcopy  printouts  or  comparable  records  of  test 
performance  and  outputs.  Formal  qualification  of  the  individual  requirements 
occurs  at  a subsequent  functional  configuration  audit  (FCA)  on  the  basis  of  the 
evidence  provided  by  that  documentation,  together  with  any  supporting  evidence 
which  may  be  derived  from  CPCl  performance  during  formal  tests/demonstrations. 


Section  3 requirements  selected  for  qualification  via  CPT&E  may  be  Identified 
directly  in  this  paragraph  (4.1.2)  of  the  specification.  However,  the  pre- 
ferred approach  to  specifying  requirements  in  this  (and  following)  paragraphs 
is  to:  (a)  construct  a summary  matrix  (the  Verification  Cross  Reference  Index; 
see  Figure  20)  which  lists  all  Section  3 requirements  for  the  CPCl,  identifying 
the  test  suDcategory  and  verification  method  for  each;  and  (b)  limit  the 
narrative  information  provided  directly  in  tills  paragraph  to  the  following 
statements: 


e A statement  that  requirements  to  be  qualified  through  this  test  subcate- 
gory are  identified  in  Column  (number)  of  the  Verification  Cross  Reference 
Index. 

• Additional  narrative  statements  that  may  be  necessary  to  further  define, 
clarify,  or  delimit  aspects  of  the  requirements  to  be  verified.  These 
should  include,  but  are  not  necessarily  limited  to,  clarifications  of 
specific  Intent  for  individual  requirements  that  are  listed  in  more  than 
one  test  subcategory,  in  the  Verification  Cross  Reference  Index.  (Tlie 
possibility  of  multiple  listings  is  discussed  further  in  3.20  and  3.21, 
below. ) 


In  effect,  the  basic  content  of  Section  4 as  a whole  is  provided  by  the  Veri- 
fication Cross  Reference  Index.  Additional  information  is  contained  directly 
in  (a)  each  of  the  paragraphs,  4.1.2  through  4.1.5,  as  necessary  to  clarify 
the  nature  or  scope  of  individual  Section  3 requirements  to  be  verified  in  the 
given  test  subcategory,  and  (b)  paragraph  4.2  to  further  clarify  the  specific 
applicability  to  identified  requirements  of  the  general  test  methods  defined 
in  paragraph  4.1.4  (see  3.21  below). 
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TABLE  XXXIV.  VERIFICATION  CROSS  REFERENCE  INDEX 


Method  L^end: 


NA  - Not  Applicable 

1 - Inspection 

2 - Analysis 

3 - Dennnstration 

4 - Review  of  Test  Data 


Test  Legend: 

A - Computer  Progranming  Test  & Evaluation 
B - Preliminary  Qualification  Test 
C - Formal  Qualification  Test 
D - System  Test 


NOTE:  The  verification  category,  test  category,  and  test  requirements  specified  for 
each  paragraph  shall  apply  to  all  subparagraphs  therein  which  are  not 
separately  listed  in  this  index. 


Section  3 
Requi  rement 
Reference 


Verifi  cation 
Method 


Test 

Subcategory 


Test 

Requirement 


4.2.7,  4.2.9 


4.2.11 


4.2.11,  4.2.12 
4.2.13 


Figure  20.  Sample  Verification  Cross  Reference  Index.  This  matrix 
is  prepared  as  a table,  normally  consisting  of  several  pages,  vhich 
should  be  located  in  the  specification  at  the  end  of  Section  4. 
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3.19.2  Support  Requirements. 


A response  to  the  phrase  "...integrated  test  program  involving  other  systems/ 
enuipment/computer  programs..."  is  always  pertinent  when  a Government  agency 
or  contractor  other  than  the  given  CPCI  developer  controls  the  availability  of 
computer  equipment,  facilities,  interfacing  CPCIs,  or  trained  operational 
personnel  that  may  be  needed  to  perform  the  development  or  to  prepare  for 
upcoming  formal  test  sessions,  hence,  statements  made  here  should  specify  the 
developer’s  needs  (requirements),  as  applicable,  in  such  areas  as: 


• Availability  of  the  computing  equipment.  Including  consoles  and  other 
input  or  display  devices,  specifying  minimum  equipment  configuration  vs. 
phasing  if  appropriate. 

• Availability  of  the  system  test  facility (ies)  for  purposes  of  computer 
program  installation  and  checkout. 


• Availability  of  other  support  to  the  CPT&E  program  if  needed — e.g.,  inter- 
facing CPCIs  or  trained  user  personnel. 


Note  that  similar  information  about  the  developer’s  needs  for  Government 
support  in  those  areas  is  not  mentioned  elsewhere  in  the  Instructions,  per- 
taining to  formal  tests.  Additional  coverage  would  normally  be  redundant, 
since  CPT&E  includes  internal  testing  in  preparation  for  conducting  the  formal 
tests.  It  is  generally  desirable  to  carry  out  PQTs  and  FQTs  as  efficiently- 
conducted  formal  demonstrations.  If  the  developer  has  "done  his  iiomework" 
properly,  he  will  have  verified  the  capabilities  to  be  demonstrated  (via  tests, 
corrections,  and  retests  as  needed)  in  advance  of  each  formal  session.* 


*Que8tions  have  been  raised  resulting  from  comparing  the  Interpretations 
presented  above  with  (a)  requirements  to  be  included  in  the  CPCI  test 
plans/procedures  and  (b)  statements  made  about  these  support  requirements 
in  Volume  II  of  APR  800-14: 

(a)  It  is  true  that  these  requirements  are  to  be  Included  in  the  CPCI  test 
plan  and  procedures.  However,  Instructions  for  the  latter  state  that  they 
"will  normally  correspond  to  requirements  set  forth  in  paragraph  4.1.1  of 
the  Part  I Cl  specification".  See  DI-T-3703,  paragraphs  l,f,(6)  and  2,f; 
note  that  the  first  sentence  of  paragraph  l,f,(6)  confirms  the  interpreta- 
tion presented  here. 

(b)  APR  800-14  (Volume  II,  paragraph  5-5, e)  also  confirms  that  the  require- 
ments described  here  are  to  be  contained  in  the  specification,  but  does  not 
clearly  Interpret  them  as  being  covered  by  the  "Integrated  test  program..." 
phrase.  It  (1)  adds  a (redundant)  statement  to  that  effect,  and  (2)  omits 
reference  to  the  use  of  Informal  test  results  for  qualification. 
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3.20  PAKAGRAPH  4.1.3,  PRELIMNARY  QUALIFICATION  TESTS 


4,1.3  Preliminary  qualification  tests.  This  paragraph  shall  specify  only  those  preliminary 
qualification  test  requirements  which  require  fonnal  recognition  by  the  Air  Force  and  are 
oriented  toward  verifying  proper  performance  of  portions  of  the  CPCl  prior  to  integrated 
testing  of  the  complete  CPCl.  Testing  accomplished  by  the  contractor  in  support  of  design 
and  development  which  does  not  require  recognition  by  the  Air  Force,  other  than  it  is  within 
the  general  terms  and  conditions  of  a contract,  shall  not  be  specified  herein.  Requirements 
for  preliminary  qualifications  specified  herein  shall  reference  requirements  in  section  3. 


PQTs  are  parts  of  the  formal  test  program,  in  that,  like  FQTs,  they:  (a)  are 
scheduled  in  the  CPCl  test  plan,  preceded  by  delivered  test  procedures,  and 
followed  by  deliverable  test  reports;  (b)  are  attended  and  witnessed  by  the 
procuring  activity;  and  (c)  are  conducted  to  demonstrate  Identified  Section  3 
requirements  of  the  development  specification. 


PQTs  differ  from  F()Ts,  basically,  in  that  they  are  conducted  on  "portions  of 
the  CPCl"  before  formal  testing  of  the  integrated  CPCl  is  initiated  (cf.  3.18 
above).  Other  differences,  and  rules  for  their  use  in  actually  accomplishing 
qualification,  are  not  clearly  established  in  current  Air  Force  policy.  The 
comments  below  suggest  a number  of  considerations  to  be  examined  and  resolved 
in  the  course  of  tailoring  this  part  of  Section  4 to  the  needs  of  a given 
system  program  and  CPCl. 


• The  instructions  in  MIL-STD-483  for  paragraph  4.1.1  regarding  different 
locations  for  PQT  (contractor's  plant)  and  FQT  (system  test  site)  are 
subject  to  some  freedom  of  Interpretation.  While  the  full  system  environ- 
ment is  typically  essential  to  completing  FQTs  of  the  system  CPCIs,  it  is 
generally  recognized  that:  (a)  most  support  CPCIs  should  be  qualified 
earlier;  and  (b)  as  much  of  the  FQT  for  mission  CPCIs  sliould  also  be 
conducted  at  the  contractor’s  plant  as  can  be  validly  accomplished  at 
that  location.  Purposes  of  the  latter  are  to  promote  confidence  in  satis- 
factory completion  of  their  development  before  committing  them  to  system 
test,  and  to  reduce  demands  for  extensive  Cl-Ievel  testing  at  the  system 
test  site. 

• The  basic  intent  of  PQTs  is  to  provide  formal  points  of  visibility  to  the 
procuring  activity,  between  CDR  and  FQT,  of  the  developer's  interim  progress 
towards  achieving  an  acceptable  end  product — i.e.,  a "confidence-building" 
function.  Nominally,  a PQT  is  intended  (based  on  hardware  precedent),  not 
to  qualify  in  itself,  but  to  demonstrate  that  the  portion(s)  being  tested 
operate  well  enough  to  Justify  their  inclusion  in  formal  qualification 
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testing  of  the  integrated  item.  Thus,  "preliminary  qualification"  really 
means  preliminary  to  qualification,  assuming  that  characteristics  demon- 
strated during  PQT  will  also  be  demonstrated  (either  explicitly  or  impli- 
citly) during  formal  qualification.  From  that  point  of  view,  many 
of  the  Section  3 requirements  identified  for  verif Ication  during  PQT  may 
also  appear  in  PQT. 

• However,  the  use  of  both  PQTs  and  selected  results  of  CPT&E  (see  3.19 
above)  for  qualification  should  be  considered  in  the  light  of  objectives 
for  the  test  program  as  a whole.  Available  time  and  resources  do  not 
normally  permit  fully  verifying  the  compliance  of  a complex  CPCl  with  the 
totality  of  its  Section  3 requirements,  even  if  maximum  use  is  made  of  all 
available  testing  opportunities.  While  PQTs  are  necessarily  limited  to 
requirements  that  can  be  demonstrated  satisfactorily  through  operation  of 
the  given  portions  (i.e.,  groups  of  CPCs),  they  also  lend  themselves  to 
greater  attention  to  requirements  of  a detailed  nature  than  may  be  appro- 
priate or  feasible  during  FQT.  Hence,  when  PQTs  are  scheduled,  the 
attempt  should  be  made  to  include  as  many  requirements  as  can  legitimately 
Se  verified  in  this  test  subcategory.  The  necessity  to  repeat  verification 
those  same  requirements  during  FQT  should  then  be  Judged  on  the  basis  of 
SI  h factors  as  criticality,  effects  of  integrated  operation  with  portions 
o£  le  CPCI  not  tested,  and  the  likelihood  of  the  tested  requirements  being 
alL  id  during  subsequent  CPCI  development. 


• Experience  suggests  that  the  total  number  of  PQTs  should  not  generally 
exceed  3 or  4,  even  for  a very  large  and  complex  CPCI,  and  that  those 
should  be  spaced  appropriately  to  their  primary  purpose  of  providing  confi- 
dence-building visibility  during  the  development  period  (ref.  II,  Ch.  VI). 

As  noted  in  3.16  above,  some  test  planning  should  be  accomplished  concur- 
rently with  the  preparation  of  Section  4.  While  the  requirements  specified 
in  Section  4 itself  do  not  identify,  for  example,  how  many  PQTs  (or  FQTs) 
will  be  conducted,  they  should  be  formulated  in  conjunction  with  at  least  a 
minimum  of  advance  planning  along  those  lines.  In  the  case  of  PQTs,  the 
requirements  that  can  be  properly  identified  in  Section  4 depend  on  the 
planned  allocations  of  Section  3 functions  to  CPCs,  together  with  the  planned 
sequencing  of  individual  CPC  development  and  assembly. 


Requirements  identified  for  verification  during  PQT  should  be  specified  in 
the  same  manner  as  outlined  above  (3.19.1)  for  CPT&E. 
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3.21 


PARAGRAPH  4.1.4,  FORMAL  QUALIFICATION  TESTS 


4.1,1  Formal  qualification  tests.  This  paragraph  shall  specify  requirements  for  formal 
qualification  tests  of'  the  integrated  CPCI  to  demonstrate  and/or  verify  that  the  requirements 
established  in  section  3 have  been  satisfied.  This  paragraph  shall,  in  subparagraphs  as 
appropriate,  specify  the  requirements  and  method  of  verification  for  the  requirements  speci- 
fied in  section  3,  with  the  following  exceptions; 

a.  The  requirement  in  section  3 has  been  identified,  and  verification  that  it  has  been 
satisfied  by  one  of  the  tests  included  in  paragraphs  4.1.2  and  4.1.3. 

b.  The  requirement  is  section  3 is  peculiar  to  category  II  type  system  testing  and  will  be 
identified  in  paragraph  4.1.5. 

Verification  of  the  requirements  may  be  accomplished  by  inspection,  demonstration,  test,  and 
review  of  test  data,  or  combinations  of  these.  This  paragraph  shall  contain  a subparagraph 
for  each  of  the  principal  methods  of  verification,  and  shall  specify  therein  the  requirements 
of  section  3 to  be  verified  by  the  method. 


The  general  aim  of  testing  at  the  Cl  level  Is  to  qualify  all  Section  3 
requirements  during  FQT.  For  reasons  Indicated  above.  It  Is  usually  desirable 
to  shift  some  of  the  burden  to  CPT&E  and/or  PQTs,  however,  particularly  for 
Individual  requirements  Involving  numerous  minor  details  or  time-consuming 
techniques  to  accomplish  their  verification.  Hence,  the  practical  emphasis 
In  FQT  Is  normally  placed  on  requirements  which  are  critical,  and  on  those 
which  can  only  be  verified  during  operation  of  the  Integrated  CPCI. 


The  specification  of  requirements  is  accomplished,  in  this  paragraph,  in  the 
same  manner  as  outlined  above  (3.19)  for  paragraph  4.1.2.  In  accordance  with 
the  above  Instructions,  this  paragraph  should  cover  al 1 Section  3 requirements 
which  are  not  specified  In  paragraphs  4.1.2,  4.1.3,  or  4.1.5.  It  should  also 
Include  (a)  requirements  which  are  specified  in  4.1.2  and  4.1.3,  but  for  which 
full  qualification  via  those  tests  Is  not  Intended,  and  (b)  requirements  speci- 
fied in  4.1.5  which  are  to  be  verified  partially,  or  in  a preliminary  way, 
during  FQT.  When  a given  requirement  appears  In  more  than  one  test  subcate- 
gory in  the  Verification  Cross  Reference  Index,  the  intent  with  respect  to  full 
qualification  is  clarified  in  narrative  statements  contained  directly  in  the 
affected  paragraphs  (l.e.,  4.1.2  through  4.1.5). 


In  addition,  the  principal  methods  of  verification  should  be  explained  in  a 
separate  subparagraph  under  this  paragraph,  along  lines  of  the  sample  content 
illustrated  in  Figure  21. 
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4. 1.4.2  Verification  Methods.  The  four  methods  identified  in  the  Veri 
fication  Cross  fteference  Index  for  verifying  individual  Section  3 
requirements  are  explained  as  follows: 


a.  Inspection  - Formal  verification  of  compliance  with  a requirement  by 
examination  of  the  assembled  CPCI  and  its  design  documentation  at  the 
time  and  place  of  qualification  testing.  Inspection  is  the  principal 
method  by  which  design  requirements  specified  in  paragraph  3.2. n of  the 
development  specification  are  verified.  It  may  also  apply  to  selected 
requirements  in  other  areas,  for  example:  to  verify  adaptation  data 
through  comparison  of  data  base  documentation  with  sample  printouts  of 
coded  data  contained  in  the  CPCI. 


b.  Analysis  - Formal  verification  of  a performance  requirement  by  exami- 
nation  and  study  of  the  computer  program  design  and  coding.  For  example, 
verification  of  compliance  with  a weapons  guidance  equation  and  specified 
tolerances  may  be  accomplished  through  analysis  of  algorithms  and  the 
flow  of  input  data  through  successive  stages  of  processing.  This  method 
is  typically  tedious  and  time-consuming. 


c.  Demonstration  - Formal  verification  of  performance  characteristics 
through  observation  of  functions  being  performed  by  the  operating  com- 
puter prtjgram.  This  is  the  basic  method  by  which  most  qualification  of 
a CPCI  is  normally  accomplished  with  respect  to  its  Section  3 perfor- 
mance requirements.  Examples  include:  ability  of  the  CPCI  -to  accept 
specified  inputs;  performance  of  specified  control  actions;  and  format, 
content,  and  timing  characteristics  of  display  or  other  CPCI  outputs. 
Verification  is  accomplished  at  the  time  and  place  of  the  demonstration 
(test). 


d.  Review  of  Test  Data  - Review  of  test  records  for  tests/demonstrations 
accomplished  at  an  earlier  time.  This  method  is  typical  of  requirements 
tested  during  CPTSE,  but  may  also  apply  to  other  requirements  which 
depend  on  a series  of  tests  over  more  than  one  test  occasion  or  under 
varied  conditions  of  operation.  Verification  is  typically  accomplished 
by  review  of  (1)  detailed  test  procedures,  including  input  data,  and 
(2)  hardcopy  printouts  of  CPCI  test  outputs. 


Figure  21.  Sample  Stalemeots  Explaining  Verification  Methods. 
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3.22  PARAGRAPH  4.1.5,  CATEGORY  II  SYSTEM  TEST  PROGRAM 


4.1.5  Category  II  system  test  prMt~ani.  This  paragraph  shall  identify  requirements  specified 
in  section  5 wnich  cannot  be  verified  until  category  II  testing  (or  equivalent)  and  must  be 
listed  as  a category  II  test  requirement. 


For  support  CPCIs  which  are  relatively  Independent  of  system  mission  functions, 
this  paragraph  is  normally  "not  applicable". 


For  mission  CPCIs,  the  basic  requirements  of  Section  3 should  normally  be 
specified,  throughout,  as  they  pertain  to  operation  of  the  item  in  the  full 
system  operational  environment.  However,  qualification  testing  during  PQTs 
and  FQTs  is  typically  accomplished  utilizing  something  less  than  the  full 
configuration  of  system  equipment  or  personnel,  and/or  utilizing  simulated 
rather  than  live  Inputs  from  external  sources.  Thus,  for  individual  Section 
3 requirements  which  cannot  be  satisfactorily  verified  under  those  conditions, 
this  paragraph  provides  for  completing  their  qualification  during  system  OT&E. 


Note  that  the  reference  is  not  merely  to  testing  at  the  system  DT&E  location, 
but  to  verification  during  the  course  of  actual  system-level  DTfcE.  An  alter- 
native to  be  considered,  when  appropriate  and  necessary,  is  to  conduct  all  or 
portions  of  FQT  for  the  mission  CPCI  during  a period  of  Cl/subsystem  DT4E 
which  may  be  held  at  the  system  test  site,  immediately  prior  to  the  beginning 
of  full  system  DT&E. 


Requirements  identified  for  verification  during  system  DT&E  are  specified  in 
the  manner  outlined  above  (1.19.1)  for  CPT&E. 
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3,23  PARAGRAPH  4.2,  TEST  REQUIREMENTS 


r 
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4.2  Test  requirements.  This  paragraph  shall  specify  the  requirements  for  each  type  of 
testing^  The  requirements  shall  include  test  formulas,  algorithms,  techniques  and  acceptable 
tolerance  limits,  as  applicable. 


This  paragraph  should  consist  of  statements  which  further  clarify  the  speci- 
fic intent  with  respect  to  how  general  verification  methods  defined  in  para- 
graph 4.1.4  (see  3.21)  apply  to  individual  Section  3 requirements. 


The  material  to  be  provided  in  this  paragraph  is  of  particular  importance  to 
the  specification  as  a whole,  in  that  its  function  is  to  delineate  techniques 
— including  limitations— of  verification  in  such  a way  as  to  provide  a feasible 
and  realistic  basis  for  the  formal  CPCl  test  program.  It  has  been  observed 
that  full  verification  of  a complex  CPCl  is  often  a practical  impossibility, 
in  view  of  the  endless  permutations  and  combinations  that  can  occur  under 
operational  conditions.  Considered  in  that  light,  objectives  of  these  state- 
ments are  to  define  and  delimit  each  verification  requirement  so  that  (a)  it 
will  provide  adequate  assurance  to  the  procuring  activity  that  the  CPCl 
complies  with  its  required  performance,  and  (b)  it  constitutes  a requirement 
which  can  reasonably  be  met  by  the  developer,  within  applicable  constraints 
of  time  and  resources. 


Hence,  the  statements  listed  in  this  paragraph  should  be  derived  from  a care- 
ful consideration  of  each  Section  3 requirement  from  the  point  of  view  of  how 
it  can  be  verified  in  a manner  which  is  not  only  adequate,  but  also  feasible 
and  attainable  during  the  DT&E  program.  In  a sense,  they  largely  represent 
assessments  of  the  practical  "testablillty"  of  various  Section  3 requirements. 
They  should  be  judged  for  their  adequacy  in  the  light  of  such  factors  as: 
effects  on  costs  and  complexity  of  the  formal  test  program;  expected  stability 
of  the  CPCl  configuration  following  its  initial  qualification;  and  criticality 
of  the  given  Section  3 requirement (s)  to  system  operations.  Those  factors 
tend  to  vary  widely  for  different  requirements,  CPCIs,  and  systems.  A few 
examples  are  provided  in  Figure. 22.  Note  that: 


» • Each  statement  is  provided  in  a separate,  numbered  subparagraph. 

• Statements  are  referenced  in  the  "Test  Requirements"  column  of  the  Veri- 
fication Cross  Reference  Index  (see  Figure  20),  for  applicable  Section  3 
requirements. 


• A given  statement  may  apply  to  more  than  one  Section  3 requirement,  and 
vice  versa. 
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4.2  Test  Requirements.  The  following  test  requirements  shall  apply  to 
Section  3 performance  and  design  requirements  as  specified  In  the  Verifi- 
cation Cross  Reference  Index,  Table  XXXIV,  within  the  Intent  of  verifica- 
tion methods  defined  In  4.1.4. 

4.2.1  Interface  requirements  specified  In  subparagraphs  of  3.1  shall  be 
verified  through  verification  of  requirements  affected  by  those  inter- 
faces In  other  paragraphs  of  Section  3. 

4.2.2  Data  base  Inputs  and  simulated  external  message  Inputs  shall  be 
verified  by  Inspection  of  hardcr-'y  printouts  at  the  time  and  place  of 
qualification  testing.  CPCI  acceptance  of  all  Inputs,  simulated  or  live, 
shall  be  verified  Implicitly  by  proper  performance  of  the  functions 
using  those  Inputs. 

4.2.3  Inputs  from  other  functions  Internal  to  this  CPCI  shall  be  veri- 
fied Implicitly  by  proper  operation  of  the  specified  function  with  Its 
Interfacing  functions. 

4.2.4  Direct  verification  of  this  function  shall  be  limited  to  demon- 
strating proper  detection  and  processing  of  error  conditions  that  can  be 
generated  by  modifying  jumper  wires,  PC  card  removal,  or  removal  of 
power  from  Isolated  components. 


4.2.n  This  function  shall  be  verified  through  verification  of  specified 
output  displays  resulting  from  manual  Inputs  at  the  console,  following 
a script  of  manual  actions. 


Figure  22.  Examples  of  Teat  Requirements  to  be  Specified  In  Paragraph  4.2. 
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Section  6 Notes.  This  section  shall  include  Information  which  Is  stated  here  for  adminis* 
trative  convenience  only,  and  Is  not  a part  of  the  speclfl  at’on  io'  me  LPtI  tn  the  contrac- 
tual sense  (I.e,,  It  shall  not  Include  requirements  which  constrain  design,  development,  and 
qualification  of  the  CPCI  and  require  lonvHence  by  the  contractor.  The  text  may  he  preceded 
with  the  statement  "AAnlnistrat Ive  Information  Only  - Not  Contractually  binding. “ This 
section  of  the  specification  shall  Include  Information  of  particular  Importance  to  the 
procuring  activity  In  using  this  particular  specification  as  a contractual  Instrument  for 
acquisition  of  the  CPCI  either  Initially  or  for  follow-on  procurement. 

Background  Information  or  rationale  which  will  be  of  assistance  In  understanding  the  speci- 
fication Itself  or  using  the  CPCI  It  specified,  may  be  included  herein  (e.g.,  technical  data 
ordering  Instructions). 


As  may  be  Infarred  from  the  above  Instructiona  (and  similar  general  policies 
for  this  section  set  forth  in  MIL-STI>>490) , there  is  no  positive  requirement 
that  any  material  be  Included  in  this  section  at  all.  Effectively,  it  is 
the  one  place  in  the  specification  where  the  writers  may  include,  for  back- 
ground or  explanatory  purposes,  cartain  types  of  information  which  are  not 
properly  contained  in  other  sections  or  in  appendices  (see  3.25  below).  The 
significant  point  is  that  information  in  this  section  is  not  really  a part 
of  the  specification,  in  chat  it  does  not  add  to  or  otherwise  qualify  any 
requlrcmencs  aCatad  in  the  basic  specification  and  is  not  directive  on  the 
developer  of  Che  CPCI. 


The  most  prominent  function  of  this  section,  in  a CPCI  Parc  1 specification, 
ia  to  provide  certain  key  items  of  background  or  explanatory  information  to 
aid  in  understanding  selected  requirements  set  forth  in  the  text  (i.e.,  in 
other  sections).  Likely  candidates  are:  Information  about  operator  proce- 
durea;  functions  of  related  CIs  or  aystems;  notes  referencing  relevant  system 
engineering  or  design  trade  studies;  or  derivations  of  selected  equations 
(cf.  3.9.2,b). 


MlL-STD-490  (paragraph  3.2.13)  provides  for  the  possibility  chat  Section  6 
may  contain  an  organised  list  of  definitions,  to  which  parenthetical  refer- 
ence may  be  made  when  terms  are  used  in  the  text.  Considering  the  policy 
governing  Section  6 in  general,  chat  appears  to  be  an  option  which  should 
be  employed  sparingly,  either  to  consolidate  definitions  which  are  alao 
provided  directly  in  the  text  or  for  terms  defined  for  information  only. 
Terms  whose  definitions  are  necessary  to  make  the  specified  requirements 
precise  should  be  defined  in  Che  text;  each  term  nay  be  defined  when  it  is 
first  used,  and/or  by  reference  to  an  organised  list  provided  elsewhere, 
e.g.,  in  an  appendix. 
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3.25  SECTIOH  10,  APPENDIX  I 


Section  10  Appendix  1.  This  section  of  the  specification  shall  contain  requirements  which 
are  contractuat^y  a part  of  the  specification  hut  which,  for  convenience  In  specification 
maintenance,  are  Incorporated  herein  (e.g.,  requirements  of  a temporary  nature  or  for  limited 
effectivlty).  Appendixes  may  be  bound  as  separate  documents  for  convenience  In  handling 
(e.g.,  when  only  a few  parameters  of  the  program  are  classified,  an  appendix  containing  only 
the  classified  material  may  be  established).  Where  parameters  are  placed  In  an  appendix,  the 
paragraph  of  section  10  shall  be  referenced  In  the  main  body  of  the  program  specification  In 
the  place  where  the  parameter  would  normally  have  been  specified.  Typical  data  that  may  be 
Included  In  computer  program  development  specification  appendixes  Include: 

a.  Mathematical  derivations 

b.  A1tema\e  method 

c.  Sumnary  of  equations 

d.  Definitions  of  terms 


(Recommended  Entry  for  CDRL  Backup  Instructions) 

Section  10  Appendix  I.  Delete  the  examples:  a.  Mathematical  derivations;  and  b.  Alternate 
methods. 


t 

ft 


Suggested  rules  for  use  of  the  appendix  fora,  and  a few  exaoples,  are  Included 
In  various  preceding  discurnions  (see  especially;  2.3.2,  Figure  A,  Figure  S, 
and  3.8.2,b). 


The  iaportant  point  of  the  basic  instructions  for  this  section  is  that  an 
appendix,  unlike  the  Notes  section  (Section  6),  is  an  integrdl  part  of  the 
specification  in  that  its  content  is  contractually  binding  on  the  developer. 

Hence,  it  is  recoaaendad  that  the  first  two  exaoples  listed  below  the  instruc- 
tions be  deleted,  since  they  both  appear  to  be  in  direct  conflict  with  that 
policy. 

I 

Questions  are  occasionally  raised  about  the  reasons  for  excluding  information 
in  such  categories  as  alternative  nethods  and  mathematical  derivations,  baaed 
on  the  observation  that  Infomatlon  in  those  areas  is  often  helpful  to  the 
computer  program  developer  (and  to  those  who  have  to  evaluate  a completed 
specification).  The  point  is  made,  for  example,  that  errors  in  mathematical 
equations  are  notoriously  frequent,  and  the  availability  of  their  deriva- 
tions can  often  aid  in  detecting  and  correcting  those  errors. 


As  noted  above  (3.24),  Section  6 is  the  one  place  in  the  specification  where 
information  of  that  nature  may  be  recorded.  It  is  obviously  limited,  in  that 
Section  6 should  be  brief  relative  to  the  specification  as  a whole.  However, 
it  should  be  recognixed  that  those  restrictions  placed  on  content  of  the 
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specification  are  based  soimdly  on  its  Intended  functions,  and  they  do  not 
iaply  at  all  that  the  inforaation  should  not  be  available! 

e Systee  engineering  and  cosputer  progran  design  study  docuaeatstlon 
resulting  froa  the  Parc  I Specification  developaent  process  should 
also  be  available  to  the  developer,  in  addition  to  the  aped fleet ion. 

In  a noraal  systea  prograa,  he  would  have  generated  auch  of  that 
inforaation  hiasalf — including  the  aatheaatical  derivations,  trade 
studiea,  detailed  operator  task  analysis  data,  etc. 

e The  requlreaents  and  constraints  placed  on  specifications  stea  froa 
a variety  of  considerations,  aany  of  which  have  been  aentloned  in 
preceding  portions  of  this  guidebook.  For  exaaple,  the  coaputer 
prograa  developaent  specification  should  be  written  as  a directive 
docuaent,  delineating  as  precisely  as  possible  Che  CPCl's  required 
characteristics  in  order  to  best  serve  its  priaary  function  aa  a legal 
instruaenc  governing  the  procurement  of  chat  itea. 


It  should  be  noted  that  the  specification  is  constrained  not  only  with 
respect  to  the  types  of  systea  engineering  data  aentloned  above,  but  also  to 
exclude  aany  ocher  levels  of  related  inforaation  which  are  contained  in  such 
docuaents  as:  developaent,  configuration  aanageaent,  and  quality  assurance 
plans;  test  plans,  procedures,  and  reports;  positional  handbooks  and  user 
aanuals.  In  a systea  prograa,  it  is  the  normal  assumption  chat  the  CFCI 
Part  I specification  will  constitute  a key  element,  but  will  be  properly 
integrated  with— and  supplemented  by->those  other  elements  of  Che  "software 
documentation"  structure  as  a whole. 
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SECTIOM  5.  ABBRgVIATIOMS 


AFLC  Air  Force  Logistics  CoasMnd 

AFSC  Air  Force  Systeas  CoaBand 

Coaasnd,  Cootrol,  and  Coaaunlcetlons 
CDRL  Contract  Data  Requlreaenta  List 

Cl  Configuration  Itea 

CPC  Coaputer  Prograa  Coaponent 

CPCI  Coaputer  Prograa  Configuration  Itea 

CPDP  Coaputer  Prograa  Developaent  Plan 

CPTAE  Coaputer  Progranalng  Test  and  Evaluation 
>DID  Data  Itea  Deacrlptlon 

DoD  Oepartaent  of  Defense 

DTAE  Developaent  Test  and  Evaluation 

ECP  Engineering  Change  Proposal 

ESD  Electronic  Systeas  Division 

FQT  Foraal  Qualification  Test(lng) 

JCS  Joint  Chiefs  of  Staff 

N/A  Not  Applicable 

0/S  Operating  Systea 

OTAE  Operational  Test  and  Evaluation 

PDS  Prellalnary  Design  Review 

PQT  Prellalnary  Qualification  Test(lng) 

RFP  Request  For  Proposal 

SAM  Software  Acquisition  Manageaent 

SDC  Systea  Developaent  Corporation 

SDR  Systea  Design  Review 

SRR  Systea  Requlreaents  Review 

TRD  To  Be  Deteralned 
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